RE: Does/should SOAP define an XML subset?

Mike Champion writes (in two separate notes):

>> On the other hand, there are good counterarguments ... 
>> I believe others on the call today were tasked with 
>> presenting them.

Indeed. I don't know that I specifically was tasked, but I'll offer my 
opinion anyway.

> SOAP doesn't. SOAP vendors probably don't care, because
> they already have to check for DTDs and PIs.  The
> larger W3C or XML community *may*, if there is a
> practical problem created by the situation where a SOAP
> message can be well-formed and schema-valid, but
> illegal as SOAP.  I'm not convinced that there is a
> real problem, but as I said it is at least an ugly wart
> on the coherence of the W3C specs.

I'm not at all convinced that the world will be a better place if we turn 
SOAP's usage conventions into a general-purpose variant of XML.    Right 
now, all XML documents are processable by all XML processors (with a bit 
of handwaving about entities and access to external DTDs.)  All SOAP 
messages sent over the normative HTTP binding are processable by standard 
XML processors.  They can be stored by all XML databases, etc.  The only 
place you might find something resembling an XML processor that can handle 
or is optimized ONLY to SOAP's conventions is buried in a special purpose 
SOAP processor, where you can't really see the difference.  That's nothing 
knew.  I wouldn't be surprised that certain XHTML editors had special 
purpose processors that handle only XHTML. 

If we promote a subset for general use, then we are blessing the 
proliferation of general purpose processors that handle only the subset. 
Now I've broken part of the key advantage of XML, which is that all 
general purpose implementations handle all XML documents.  I claim that 
this is very, very different from allowing optimized special purpose 
processors in particular environments, such as XHTML editors or SOAP 
processors.

True, if you are choosing to use a general purpose parser to build your 
XHTML editor, you have a lot of checking to do that the based parser 
doesn't do for you (though a validating parser helps.)  Exactly the same 
for SOAP.  If you choose to use a general purpose parser, you'll have to 
add your own checks to make sure what you get is really SOAP (starts with 
an envelope, doesn't use PIs, etc.)

> We discussed this at a Web Services Architecture
> meeting awhile ago, and the consensus was that it's
> really XML's problem, because XML is not embeddedable /
> composable (and entity expansion creates memory
> management challenges for parser implementers, etc.).

Whoa, I think this is a different and much bigger problem.  Yes, XML has a 
big problem in that you cannot in general embed complete XML documents in 
other XML documents.  Yes, SOAP's "subset" comes a bit closer, but even 
SOAP's subset doesn't really achieve such composability, and it wasn't a 
goal.  For example, a nested fragment can pick up namespace bindings from 
its parent. 

If the goal of core is to start thinking about how to make composeable 
XML, that's an interesting and challenging question, but I don't think it 
particularly supports a quick move to "bless" SOAP's XML conventions as a 
general purpose XML subset.

Thanks!

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Thursday, 8 May 2003 14:59:20 UTC