RE: why no doc type declaration and PIs in SOAP?

> -----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