Re: Possibility of an XML Document Type

Noah,

Please see my comments below.

Cheers,

Chris

Noah_Mendelsohn@lotus.com wrote:

>Several responses to this proposal have come in.  To save email, I'll
>respond to all I've seen here in one mail.  First, thanks to the many who
>said this was an interesting direction to explore.
>
>Rich Salz writes:
>
>>>SOAP with attachments would also address this, right?
>>>
>
>It's an option, but I think you lose a lot.  You can't process the
>attachements as XML.  You can't run them in an obvious way through XSL or
>XPath.  They wouldn't obviously get stored in a database with the message.
>This option would be for cases where you really want the document in the
>message.  There will be a cost, for the bin64 or whatever encoding.
>

This isn't a correct characterization at all. You CAN access attachments 
with creative use
of an URIResolver for the MIME multipart envelope. You CAN indeed 
process the SOAP
envelope AND the attachments using XSLT and a URIResolver that is aware 
of the MIME
envelope. You can also effectively slurp an attachment XML document into 
the SOAP Body
element using an XSLT document() call and a URIResolver. This is pretty 
straightforward
stuff. You do NOT need to have the document physically *in* the SOAP 
envelope when
it is on the wire, and IMO it is pretty trivial to make it appear as if 
it were.

<snip/>