- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Fri, 16 Aug 2002 09:14:45 -0400
- 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 UTC