Evaluating XML for Protocol Control Data

Reasons to Fear XML Headers

A header is a piece of metadata associated with a message or file. An XML header is just a header expressed in XML syntax

• Verbose
• Harder to type (somebody has to type them, if only library implementors)
• Tricky (but not impossible) to integrate into existing MIME systems like HTTP and SMTP

Problems seem minor.

Reasons to Love XML Headers

• Arbitrarily complex structure
• Can easily build on XML Schema data types
• Can easily be annotated "mustUnderstand"
• Can explicitly label the intermediary or resource that the header is directed at.
• Can use XML namespaces to avoid name clashes
• Unicode support for free

Advantages seem major.

Reasons to Fear XML Envelopes

An "XML Envelope" is an XML document that wraps up XML headers with an XML body or "payload"

• Pathetic at handling non-XML (especially binary) payloads.
• Demonstrably not sufficient for non-binary data.
• Binary data solutions not-standardized and perhaps patent-encumbered.
• If the payload is XML, it might be a complete document with a leading XML declaration. That isn't legal so it would have to be treated as if it were non-XML.
• There are all sorts of hairy issues relating to the interpretation of (e.g.) xml:base, namespaces in general, XPointers that point to the root etc. You must keep all of these in mind doing XML processing of documents that use XML for both envelope and payload.
• Merging and splitting payload from envelope requires XML processing which is more expensive than MIME processing.
• Envelopes cannot transmit potentially malformed data without encoding it somehow.
• Tends toward conflation of protocol and payload.

Potential patent problems around XML envelopes:

• DIME: "The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights."
• DIME: "The presentation, distribution or other dissemination of the information contained herein by Microsoft is not a license, either expressly or impliedly, to any intellectual property owned or controlled by Microsoft."
• SOAP With Attachments: "IBM may own patents or patent applications which apply to the SOAP Attachments specification being submitted to the W3C. If implementation of a W3C standard based on the SOAP Attachments specification requires the use of IBM patents, IBM will grant, upon written request, a non-exclusive license under such patents on reasonable and non-discriminatory terms."

These problems seem major.

Reasons to Love XML Envelopes

• Trendy?
• Dig the radical recursiveness of it all?
• Ability to handle the whole message as one unit with XML processing tools like XPath and XSLT.
• Others solicited!

Advantages seem minor.

Conclusion: we need to work out standardized ways of using XML headers in MIME envelopes so that we can have the best of both worlds. XML envelopes seem to have no serious advantages.

Quotes

From where I sit the biggest problem with SOAP as an envelope is that it isn't transparent. The payload has to be XML (what about my GIFs?) and the XML can neither have PIs (what about my XML declaration?) nor DOCTYPEs (what about my entities?). This means that it cannot transport many XML standards as is.

John F. Schlesinger

This was a big can of worms that unexpectedly popped open at the SD2002 SOAP BOF last week. Some participants were adamant that they needed to consider and act on the envelope irrespective of the contents of the body, even if the body was malformed. For example, they wanted to be able to do forwarding and error reporting rather than just dropping the malformed message on the floor.

If they're right, and this is a common need, then I have to say, as I did then and there, that SOAP is fundamentally flawed, and cannot be repaired. The requirement to mix envelope and body in a single XML document is irreconcilable with the need to process the envelope independently of the body. Thus we pound one more nail into SOAP's coffin.

Elliotte Rusty Harold in <p0433010ab8f200e74e43@[192.168.254.4]>