- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Thu, 20 Sep 2001 12:12:35 -0400
- To: xml-dist-app@w3.org
> -----Original Message----- > From: Jacek Kopecky [mailto:jacek@idoox.com] > Sent: Thursday, September 20, 2001 11:39 AM > To: xml-dist-app@w3.org > Subject: why no doc type declaration and PIs in SOAP? > > > Hello all. 8-) > I couldn't find it in archives Check out the thread starting at http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0289.html Andrew Layman replied: "The historical context for the prohibition against processing instructions in SOAP was that some people believed that processing instructions were too expensive for small devices. This was swept up as part of a larger conviction that DTDs were too expensive. I do not believe that the actual cost of processing instructions was considered separately and in detail. I deserve the majority of the blame for the decision. Frankly, given the benefit of more time to think about the matter, I now think that allowing them would have real benefits and little cost." > What are the reasons for disallowing document type declaration > and processing instructions in SOAP? Will we keep the > restrictions in SOAP version 1.2? As it is now, SOAP grammar is a > subset of XML. I'd be inclined to believe that: - Processing Instructions are -- by definition -- not interoperable between applications, are likely to be discarded by many XML processors, and imply an out-of-band contract between the producer and consumer of an XML message. As such, they don't add much value to SOAP, but do add a (possibly negligible) overhead to developers of conformant processors and non-negligible complexity to the practical problems of SOAP interoperability. - Keeping DTD information out of SOAP messages (of course, I'm talking about the information in the SOAP namespace, not the payload) keeps the lid on a large can of worms. Without a DTD, you can't declare entities, notations, default attribute values, and other stuff that significantly limits the interoperability of XML in practice. I'll guess that the subset of XML that SOAP now uses could be defined in about 15-20 EBNF productions instead of the 90 or so that XML 1.0 employs. - As I argued in the xml:base thread, SOAP *uses* XML, but a conformant SOAP processor shouldn't have to be a general-purpose XML processor. Sure, there are plenty of more-or-less conformant XML processors on most platforms that can be used as the basis of SOAP processors. Nevertheless, I suspect that insisting on full XML conformance by SOAP processors will limit its utility in very "light" environments. So, I would want to be convinced that the benefits Andrew Layman speaks of are really and truly worth the costs before re-visiting this decision of the SOAP 1.1 people.
Received on Thursday, 20 September 2001 12:12:36 UTC