XML envelopes and headers

Elliotte Rusty Harold wrote:
> 
>...
> 
> 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.

Here are my own biased thoughts on this issue:

http://www.prescod.net/xml/envelopes/

       Evaluating XML for Protocol Control Data

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


     * 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 a package that wraps up XML headers with an XML
   body or "payload"
     * Pathetic at handling non-XML (especially binary) payloads.
     * Demonstrably [1]not [2]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.
       
   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.

References

   1. http://www.w3.org/TR/SOAP-attachments
   2. http://www.gotdotnet.com/team/xml_wsspecs/dime/default.aspx