W3C home > Mailing lists > Public > xml-dist-app@w3.org > August 2002

RE: Problem with resolution of Issue 221

From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
Date: Fri, 16 Aug 2002 09:14:45 -0400
Message-ID: <9A4FC925410C024792B85198DF1E97E403D0958B@usmsg03.sagus.com>
To: xml-dist-app@w3.org



> -----Original Message-----
> From: Martin Gudgin [mailto:mgudgin@microsoft.com]
> Sent: Wednesday, August 14, 2002 11:12 AM
> To: Williams, Stuart
> Cc: xml-dist-app@w3.org
> Subject: RE: Problem with resolution of Issue 221
> 
>
>  
> So we may as well make both of them MUST ( or SHOULD ) or, my 
> preference
> would be to stop trying to subset XML, say nothing about DTDs or PIs
> except that our spec doesn't define any processing rules for them.
 
At the risk of re-opening a can of worms, this might be the basis for a
reasonable solution.  We need to think about the intent of banning DTDs and
PIs in the first place.  It was before my time, but I suspect it was
something like:

- PIs are generally used as a "secret handshake" targeted to a specific
application, and relying on them causes all sorts of problems in the SGML /
XML document world, especially when a new "intermediary" application is put
into the picture that doesn't understand the PIs and mucks them up somehow.
Since SOAP wanted to define a "contract" for how messages would be
processed, and PIs are sortof an "off the books" understanding, banning them
seemed like a good idea.

- DTDs / Doctypes don't compose well, i.e. you can't wrap an Envelope around
a document with DTD info in it.

- DTDs open the trapdoor to interoperability Hell for non-validating XML
parsers; the XML 1.0 spec is very permissive (i.e., underspecified) as to
what a nonvalidating parser should do with undeclared entity references,
external entity references, default attribute values, etc.  

Thus, since we (or our predecessors) didn't want to force SOAP
intermediaries to have validating parsers, and didn't want to force
intermediaries to re-arrange Doctype declarations / DTD internal subsets
when they added headers, and didn't want to encourage non-contractual
understandings between endpoints that intermediaries couldn't respect, just
banning DTDs and PIs seemed like a good idea.

I guess in retrospect, I agree with Gudge's wording about PIs -- just say
that they must not affect the SOAP processing, but intermediaries should
treat them like anything else in the XML InfoSet and pass them on intact.

DTDs still seem like a bottomless pit; are they even fully represented in
the InfoSet?  Can we just get away with saying that we don't define any
processing rules?  It would seem that we would have to add a bunch of stuff
in the spec to say how an intermediary should escape a DTD so that it can
compose XML that contains it, or move it to the top of the SOAP message, or
a bunch of stuff that's at the syntax level rather than the InfoSet level.

I wish/hope we could dodge this bullet, but the problems here are created by
the XML spec, not SOAP.
Received on Friday, 16 August 2002 09:14:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:10 GMT