W3C home > Mailing lists > Public > www-tag@w3.org > February 2002

Re: Namespace dispatching

From: Tim Bray <tbray@textuality.com>
Date: Tue, 26 Feb 2002 16:12:55 -0800
Message-Id: <5.1.0.14.2.20020226160815.0232a860@pop.intergate.ca>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:04 GMT