- From: Tim Bray <tbray@textuality.com>
- Date: Tue, 26 Feb 2002 16:12:55 -0800
- To: TAG <www-tag@w3.org>
At 10:45 AM 19/02/02 -0500, Simon St.Laurent wrote: >On Tue, 2002-02-19 at 09:02, Paul Prescod wrote: >> I think I understand from the IRC logs that the idea is that the world >> of XML documents will be divided into two sets, those where the >> top-level namespace allows dispatching and those where it does not. The >> latter documents must not be shipped with a +xml suffix. > >If the latter is the case, that's an enormously creative >reinterpretation of RFC 3023 that I don't find plausible. > >+xml indicates that the document is XML, per XML 1.0. It makes no >requirements whatsoever of particular namespace usage, nor do I believe >it should. There's a real issue here that I hadn't seen until TimBL raised it. The chief motivation for the +xml idiom is to support generic-XML processing. Some people don't believe in such a thing, but I can think of examples: harvesting XLinks, finding chunks of Japanese text, and so on. I think that in the general case this is a safe and reasonable thing to do. The point is that if a resource is in XSLT (and coming soon I expect XQuery) such processing becomes arguably highly unsafe, because what this thing produces is not what the resource looks like... for example, you could have xml:space elements in templates that totally do *not* apply to the xsl directives in their contents. Mind you, this is probably a really obscure corner case, because processing an XSLT doc standalone as an XSLT doc is a distinctly weird thing to do. -Tim
Received on Tuesday, 26 February 2002 22:57:12 UTC