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

> 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?

It's not that you can not find examples like this, it is just that they
all depend on the assumption that the namespace name is (at some point)
used to retrieve a schema or some other information. Clearly such a
proposal is not unreasonable but it was explictly "not a goal" of the
namespace REC. I gather that there were perhaps internal debates prior
to the release of the namespace rec but for those who don't (or, in my
case, didn't) have access to those discussions at the time, the natural
thing is to take current specification at face value. 
The namespace REC goes to some lengths to stress a character by
character comparison, and the fact that there need not exist any
retrievable resource. In fact the examples given would also apply
to URI identity rules, so don't decisively determine the situation
hence the current mess, but the clear implication of the current
namespace REC is that the namespace name is just that, a name, a
string, but by using as the namespace name a URI over which you have
some control, that name clashes may be avoided.

Note however that it appears to be only be Gentlemen's agreement
that clashes are avoided. I can not edit the file that is returned by
http://www.w3.org, but I can put an element in a namespace with that
name, <xxx xmlns="http://www.w3.org"/>, see I just did. Depending
on the jurisdiction I may have contravened some laws of fraud or
trademark infringement, but I don't believe I contravened the Namespace
REC.

The rules for namespace declarations are in any case different than the
rules for URI references (different interpretation of the empty string).

It seems that in many respects the `relative namespace URI' issue is a
red herring, as has been commented, it only affects a small (and
probably in future negligible) fraction of documents anyway. The real
issue is this re-interpretation of the namespace name to being the
schemaLocation. Tying the namespace name to the schema for the
vocabulary has many bad effects and duplicates functionality provided
elsewhere, eg the SYSTEM literal to refer to a dtd or a schemaLocation
attribute to refer to a schema. Having these separate from the namespace
name allows the schema location to be changed without changing the
namespace used for the document (which would break any applications that
were making namespace aware selections into the document), although of
course having some catalogue system that defaults schema based on the
namespace would also be useful.

However if the intention is that somewhere in the future there will be
some canonical format that should be placed at the namespace URI, the
REC should be re-issued to ban me using your web site, and ban URI
schemes such as mailto: or telnet: otherwise documents are going to get
created now that will be orphaned later.

David

Received on Wednesday, 17 May 2000 05:32:24 UTC