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

-----Original Message-----
From: Simon St.Laurent <simonstl@simonstl.com>
To: John Cowan <jcowan@reutershealth.com>; xml-uri@w3.org <xml-uri@w3.org>
Date: Tuesday, May 16, 2000 2:28 PM
Subject: Re: Are *relative* URIs as namespace nemes considered harmful?


>At 02:19 PM 5/16/00 -0400, John Cowan wrote:
>>keshlam@us.ibm.com wrote:
>>
>>> Relative URIs are a fine thing when you want them to resolve differently
as
>>> you move a group of files from place to place. But namespace names do
not
>>> want that behavior; the expanded name {nsuri}localname wants to stay
>>> _stable_ as the document is relocated.
>>
>>Well, then don't use them if that's the property you want *your* names to
>>have.
>
>But to be rude, are there any real cases where different namespace
>resolution based on file location is actually desirable?


(I think you mean document base URI.  I wish people would not always equate
URIs with filenames. But the question is still good)

>_Should_ anyone use relative URIs, and should that extra processing be
>expected of all namespace processors?
>
>Simon St.Laurent


This is indeed an issue between only two outcomes which seem to me
reasonable (forbid relative URIs or absolutize them for comparison).   I do
indeed imagine that this would be rare.

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 "#".

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.

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?

(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.)

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).

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.

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.

Tim BL
with no director hat!

Received on Tuesday, 16 May 2000 18:09:46 UTC