message schema design guidelines?

Is there some recognized structured guidance for message schema design?  In other realms of software development than XML messages, we are guided by structured principles like refactoring and normalization and denormalization.

I want to design messages well for my company's new service oriented architecture.

My preferred architectural process is the following for SOA, based on some nice SOA presentations I watched:

1- Start with a review of a business process or use case.

2 – Design message schemas which match this business process. 

3 – Prefer to make messages more chunky (more comprehensive), not so much chatty (avoid small, atomic-messages mapped to atomic transactions).  Public SOA interfaces should be, to borrow a term from data warehouse design doctrine, more like denormalized schemas which match closely a specific business process and not some underlying storage or transaction system implementation.

Questions

Should message schemas be, to borrow a term from coding doctrine, *refactored* into reusable and containable parts? 

Should these then be efficienty combined into composite message schemas which show themselves on the public SOA interface as big chunky messages? 

 Does BizTalk support message schema refactoring well?  

 Does BizTalk support the resultant need, for many little refactored message schema-atoms to be composed and aggregated into larger final message schemas?

 Thanks for reading.  I think I want a structured mature approach rather than ad-hoc "on a case basis" becuase that style usually just indicates a lack of understanding in my experience, and such "case basis" applications result in just a big mess that nobody can understand.