Thursday, 5 August 2004
The ‘Document’ in Document-Oriented Messaging
(Another instalment in “XML Heresies.”)
One of the foundations of most vendors’ approach to Web services is called document-oriented messaging. This is the notion that interoperability is improved by describing a protocol in terms of the artefacts that are exchanged on the wire, rather than how the code that handles them is written.
As far as it goes, that’s good advice. Implementation-specific specifications lead to brittleness, because you can’t swap out the implementation; the message is too tightly coupled to the code. It also isn’t exactly new; although CORBA and DCOM got this wrong, the IETF has been writing protocols in this fashion for quite some time, very successfully.
What’s interesting is the baggage that comes along for the ride. “Document-Oriented” invariably means “XML” to many people; the reasoning being that you can break the link between implementation-specific data structures and wire formats with what is becoming the lingua franca of document formats.
Everybody Needs a Data Model
That’s great, but you still need some way to tell people what it should look like. When you specify a message’s content — whether you’re doing so in an IETF, W3C or OASIS protocol, or in an ad hoc Web services protocol — you need to do so based upon some common abstraction (a.k.a. data model) — even if it’s the Unicode character set — and a means of constraining it (e.g., a schema language).
Note that this is not at all at odds with the idea of document-oriented messaging. The important thing is that the choice of the data model and schema language should not be driven by implementation-specific considerations (e.g., your favourite language’s object model); they should be a vendor- and implementation- neutral, which is one of the reasons that XML has had so much fanfare.
Many alternatives are available to make this job easier; for example, EBNF, DTDs, XML Schema, Relax NG, and OWL all allow you to describe such constraints. With them, you can talk in a shorthand while still being precise about the bits that go on the wire. As a bonus, abstractions give some wiggle room for alternate serialisations, and can also provide tools and patterns for common tasks like extensibility and versioning.
Is XML Schema Right for Web Services?
The whole idea of Web services is to give people a protocol construction toolkit that allows them to easily specify messages, suck them into code and start working with them easily, on most any platform. So, why is it that that Web services went shopping for these things and come back home with the XML Infoset as described by XML Schema, of all things*?
As discussed before, an Infoset isn’t exactly a simple thing; in fact, there are very few bindings to programming languages that capture all of the information in an Infoset, and even fewer of them do it in an intuitive manner**. Instead of mitigating this complexity, XML Schema revels in it.
Think of it from an information theoretic standpoint; if the various Information Items and properties of an Infoset are each capable of carrying information, we’ve got a pretty big footprint to work with, and Schema doesn’t give very precise tools for sorting the signal from the noise. Because each different tool chooses a different, incomplete portion of the Infoset to model, interoperability is hard.
For examples of this in existing specs, look at Atom — an extensible metadata container where the order of children is insignificant. It’s impossible to describe this in XML Schema; if you make something unordered, it can’t be extensible. Another ironic example is WSDL 2.0; rather than using the Infoset as a data model, WSDL 2.0 describes a new one — the Component Model — mapping it to an Infoset and then to bits on the wire. Why do Web services folks think it’s OK for end users to use XML Schema if it isn’t good enough for describing WSDL?
In both of these cases, an implementation-generic data model and set of constraints upon it was necessary, and XML was chosen as the way to serialise bits on the wire. Great. However, XML Schema falls short of describing what’s really going on; something more is needed.
Compared with what came before it, XML is the bee’s knees. It isn’t implementation-specific, yet widely-deployed. It’s openly specified and unencumbered, and human-friendly to boot. It also offers some very useful advantages over its predecessors, such as nesting and the potential for versioning and extensibility.
However, XML was made for document markup, not data modelling. XML Schema does what it’s supposed to — it describes constraints upon the XML Infoset — with complete coverage, but it misses the boat; by trying to do all things, it makes doing simple things really difficult. The result is — for data-oriented use cases — a complex data model not designed for the task at hand being described by a sub-optimal constraint language.
Don’t get me wrong; XML is a great foundation for syntax, but data models that directly map to it (such as the Infoset, PSVI, XQDM, etc.) are a horrible basis for a generic, interoperable protocol toolkit.
Many people think that Relax NG is the answer, but I think this view misses the deeper problems caused by its continued reliance on the Infoset as a data model. While some people do actually want to shove markup around, the more prevalent use case by far is simple data.
The real trick, IMO, is getting the advantages of XML — like platform neutrality, versioning, extensibility, nested data structures, self-description and human readability — without the complexity of the Infoset or the problems of XML Schema. A simpler, higher-level data model that has a mapping onto the Infoset while still providing these things could do the job.
The question at hand is whether we can profile and subset XML Schema and the Infoset to the point where they’re usable for modelling data, or whether we should start fresh. On the former approach, it’s interesting to see that WS-I has created a Schema Profiling Work Plan Working Group (PDF link), although I don’t know it’ll be able to go far enough***. Arguments that breaking a large number of existing schema instances is bad are also persuasive.
As far as starting fresh goes, we might be able to just switch horses. A little while back, I made a direct comparison between the two stacks that the W3C is developing; one based on the Infoset, the other on the RDF data model. It’s pretty clear to me that the RDF data model is simpler; the next step, I think, is to see if and how it (along with OWL) provides the purported benefits of XML, such as nesting, extensibility and versioning. The first of these is pretty easy (it’s a directed graph, so it’s arguably superior); the latter two are beginning to be explored. Stay tuned.
* Note again the advent and fall of SOAP encoding; it had a simpler data model, but didn't have an effective description mechanism in SOAP 1.1, hence WS-I dropped it in the Basic Profile. You need both parts.
** Before you pipe up and claim that [insert your tool of choice] can do it, consider this; how easily does it expose element ordering? Attributes? Namespace prefixes used? Comments? PIs? The DTD?
*** It bears repeating that this Web site represents my personal opinions and musings only.