I think that representing messaging data with xsd normally drives you to build highly coupled systems.

We had a services solution, internally implemented with OOD,  that provided access to the backend. We changed everything to build an "Enterprise Service Bus" solution based in:

- MSE (http://servicesengine.codeplex.com/)  Data defined in xsd.
- ESB using dinamics ports, etc.
- Biztalk 2009  (Maps, Schemas...)
- WCF Services.


Results

- These tools/frameworks push you to express the data with XSD.
- Biztalk visual studio tools forces you to include the schema inside a dll.
- Extra job, everything has to be expressed in schemas.
- Even very little messages needed to be validated against a XSD.
- Performance is worse than the previous solution (online, mobile..).
- The architecture is oriented to the tool, no to the business problem.
- Sometimes you add XSD logic to the business logic, I mean, you can see people asking XSD questions to the business team.
- The new solution is not more robust, is just bigger (schemas).


It seems to be a robust system but as you have already explained..

Consecuences

- We had services that we wanted to reuse to build some composite services.

- To reuse service A in service B, a developer took the decision to add the reference of project A schema into B.

- Weeks later, a very minor change, we wanted to add an optional field for data A schema, so we added the field in the A project and try to deploy.

- The schema is a resource in the dll project. So, it has dependencies.

- We had to stop aplication B in all the servers.

- Was not enough.  We needed to undeploy the application B.

- Stop all processes.

- With the system down, the application undeployed, we could deploy the new schema into Biztalk.

- Deploy again application B.


Next Steps


Quick but not best solution  (again.. is no the best solution)

- Use a generic schema that never changes as a container.
- Delete the DLL  and use the schema as a file. 

For the next big release we will try reduce all this XSD coupling to the minimum.  We will build an API based in http, at least not based in data schemas.  We will implemented our validation class based in norm documents o tables.   I agree with your aproach of having a tupla, key, value (or something similar).   I found also interoperability problems with some java framework implementations using multivalue arrays.


Thanks a lot for sharing