- From: Tim Bray <tbray@textuality.com>
- Date: Mon, 25 Nov 2002 13:34:53 -0800
- To: Paul Grosso <pgrosso@arbortext.com>
- Cc: www-tag@w3.org
Paul Grosso wrote: > It is my understanding that the Last Call draft of SOAP 1.2 [7] makes > use of an XML format that does not permit any internal subset, despite > the fact that XML 1.0 does not define such a profile/subset of XML. I > wonder what the definition of such profiles by individual specifications > will do for interoperability. I hate to say it at this late date, but I think Paul's really got a point here. In particular: - The IETF has recently adopted Guidelines for the Use of XML Within IETF Protocols as a Best Common Practice (see http://www.ietf.org/internet-drafts/draft-hollenbeck-ietf-xml-guidelines-07.txt, and there's HTML at http://www.imc.org/ietf-xml-use/xml-guidelines-07.html). It specifically in section 4.3 "Syntactic Restrictions" advises against doing what SOAP 1.2 is doing. I think the Web Services community ought to be real nervous about flying in the face of an IETF BCP. The BCP is really well-written on this point and worth checking out. - On the other hand, I think it's entirely reasonable that SOAP agents be forbidden from being required or expected or even allowed to charge off fetching DTDs or external parameter entities at run times, for obvious performance and security reasons. - That granted, forbidding an internal subset seems kind of dumb. Speaking as an XML processor implementor, the extra code required is hardly detectable and the performance gain not significiant. Furthermore, every XML processor in the world just silently does the internal subset and it's going to cost *extra work* for SOAP implementations to check that they haven't. I.e. you can't use an ordinary off-the-shelf non-validating XML processor. - I'd be willing to bet that at least some SOAP implementations don't bother to implement this restriction, which raises real interoperability issues. Does that have an impact on CR exit criteria? -Tim
Received on Monday, 25 November 2002 16:34:55 UTC