It is this aspect of interoperability that is missing. People have been taught to think in terms of schema and do my XML components match yours? Instead we need to think in terms of business components, collections, properties, context and roles and especially in terms of services and business processes.

Too often people have created uber-XML without regard for the business purpose and processes, so their XML contains the kitchen sink of components, thereby preventing people using their pre-built schema in any interoperable way at all.

Back in the day with ebXML we talked about contracts and exchange profiles and templates where you can dynamically engineer information collections from core components and then share that coupling via templates. That whole notion was disregarded by the W3C who instead provided fixed XSD schema as the answer.

Now these ideas are making a come back thanks to the growing acceptance of the SOA approach and notion of adaptive web services as the foundation for information exchange. So once again the whole idea of common business definitions is vital to enable that.

Looking forward to your Part 2 next.