W3C home > Mailing lists > Public > xml-uri@w3.org > May 2000

Re: Are *relative* URIs as namespace nemes considered harmful?

From: Simon St.Laurent <simonstl@simonstl.com>
Date: Tue, 16 May 2000 19:18:46 -0400
Message-Id: <200005162316.TAA15295@hesketh.net>
To: <xml-uri@w3.org>
At 05:53 PM 5/16/00 -0400, Tim Berners-Lee wrote:
>One example, given by Chris Lilley I think, from WebCGM experience, is that
>of a schema which defines a language and sees it in the same document in a
>deliberately (not accidentally) self-referential way.  [The C program module
>parallel would be a program file which defines a number of functions, and
>makes calls  to those functions within the same file which defines them.]
>For example, the schema for schemas could bootstrap itself into existence
>referring to itself as "#".

I'm not sure I see where this is either useful or meaningful, except as a
convenience to the editor.  Perhaps it's an extremely explicit version of
Walter Perry's 'every document on its own terms', but I'm not sure that
namespaces are necessary or even useful in such a case.  The schema for
schemas might be a lot smarter to bootstrap itself with an explicit
reference to a fixed version.

>Another example is a suite of schemata which define interrelated languages,
>so that for example a Shape-based Vector Graphics and a Spline Vector
>Graphics and Spatial vector Graphics schemata are published as a trio and
>use each other's namespaces. he editor just finds that editing the three
>documents is easier with relative URIs as it is always important in the
>various drafts and versions and branches of discussion that the three
>schemata refer to each other, and it is really burdensome and error-prone to
>have to change the namespace declarations whenever a different variety of
>the specs is produced.

Again, I don't find this convincing.  'Editing with relative URIs' is
always easier, _if_ you're tracking the URIs manually.  If you're really
running a project like this, I'd strongly suggest that you're well past the
point where using convenient shortcuts is a good - or safe - idea.

>So there we have two made up examples - they exist.  Are we to be able to
>predict the uses of XML namespaces so clearly that we can guarantee no more
>will arise?

Are we willing to sanction a usage in which it's quite clear that users can
change vocabularies through actions (like copying files) that normally have
no such side effects?

(Heck, I don't get to sanction anything.)

>(Examples have also bee quoted in other fora of software which accepts
>relative URIs and documents which have been written to take advantage of
>that fact.)

The existence of those examples has not yet been demonstrated.

>If you find these two unlikely, then that is still not a reason to ban
>relative URIs. There is also the argument that says that really people are
>in fact extremely unlikely to misuse this feature because almost all
>namespace names will be absolute (as there will be no common root with the
>document base address anyway).

In any event, I'll be adding large WARNING notes to every one of my XML
books suggesting strongly that users avoid this so-called feature.  Sadly,
my books are becoming festooned with such warnings as the interactions
between XML 1.0 and itself and XML 1.0 and namespaces become clearer.

(For examples, see either my book XML Elements of Style, Part 4, or the
Common XML draft spec at http://www.simonstl.com/articles/cxmlspec.txt,
which is pretty much a list of such warning labels.)

>But if you ban them, you move from a situation in which there are two
>concepts in the grammar, a URI and a URI reference, to one in which there
>are three: a URI, a URI reference, and a URI reference constrained to be
>absolute.  The last does not exist in the grammar at the moment. Defining it
>complicates life.  Any agent which processes XInclude and/or Xlink or xHTML
>must anyway have the concept of a URI reference.  Most software which does
>anything, including XPath and XSL to take recent examples, must be able to
>handle relative URIs. So if you imagine that saving the hassle of
>absolutizing a URI reference will simplify the code - then what happens when
>your code hits an XInclude? Do we have the whole argument all over again?
>It is much easier to think of likely examples for XInclude. And XInclude
>processing is also crucial to the integrity of a document.  You are going to
>have to have the base URI available in fact, and avoiding using it for
>namespaces just puts off the question until the next layer of code.

I'm not sure that everyone in this discussion considers XInclude and XBase
to be a good idea.  Creating a URI reference constrained to be absolute
doesn't seem like a horrible sacrifice.

>Those are some counter arguments  as I see it.  I could *imagine* living
>with the banning of relative URIs in order to allow base-URI-awareness
>(including XInclude processing etc) to be moved a level above the DOM,
>leaving the DOM base-uri-unaware is it is proposed.  (I think such an
>architecture is broken, as I believe that XInclude processing should take a
>document at one level of abstraction and yield document at the same level of
>abstraction.).  Banning relative namespace URIs could be a compromise.

I can imagine living without the banning of relative URIs, but I think at
some point we'd have to give up on the fable of interoperable and reliable
markup applications.  We've been headed that direction for a while, so it
may not be so great a sacrifice.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
Received on Tuesday, 16 May 2000 19:16:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:58 UTC