- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 25 Nov 2002 14:15:06 -0800
- To: "Tim Bray" <tbray@textuality.com>, "Paul Grosso" <pgrosso@arbortext.com>
- Cc: <www-tag@w3.org>
> I think the Web Services community ought > to be real nervous about flying in the face of an IETF BCP. Why? It's a Best Current Practice, and it is explicitly scoped to use of XML within *IETF* protocols. It's just that community's best current thinking (words directly from RFC2026) on a particular topic, and may (dare I say probably will) change. Granted, if there is a desire to make it possible to use Web services as the basis of IETF protocols, there might be cause for concern; however, that isn't a requirement that I've heard for a while, and I imagine that the IETF isn't terribly inclined to start using them willy-nilly either; Web services have a different audience. Also, at first glance, the logic in that document seems to be faulty; it says one shouldn't impose "additional restrictions beyond those imposed by the XML recommendation itself" because "an implementer of the protocol may not be able to use an otherwise conforming XML processor to parse the XML-based protocol elements." If they are truly restrictions, how could a conformant processor not be able to parse the result? I grant that a vanilla conforming generator *may* have difficulty, depending on the abstraction that it presents to the programmer. > - 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. This gets to the heart of the question, I think; can specific applications of XML restrict the use of syntactic mechanisms it defines? Your answer seems to be a conditional "yes." However, I don't think it's supportable to be selective, at least at this granularity. > - 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. Perhaps the WG has a good reason for this prohibition; have they been asked?
Received on Monday, 25 November 2002 17:16:45 UTC