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

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

From: Jonathan Robie <Jonathan.Robie@SoftwareAG-USA.com>
Date: Wed, 17 May 2000 09:53:57 -0500
Message-Id: <>
To: xml-uri@w3.org
At 03:14 AM 5/17/00 -0400, Tim Berners-Lee wrote:

>On the contrary, there is a serious one: you get things which were
>(identical, not identical) when compared as strings turning out to
>generate (not identical, identical) objects when
>considered as URIs.  This seems to me to be untenable.

I want to make sure that I understand what you want. Are you saying that 
two namespaces should be considered the same if and only if their URIs 
resolve to the same resource? If so, must a physical resource be created in 
order to create a namespace?

Also, let me make sure I have my facts straight. I assume that when string 
comparison says two URIs are equal, they identify the same resource (if 
such a resource exists). If string comparison says two URIs are unequal, 
they may still be aliases for the same resource. To me, this does not seem 
inconsistent for the purpose of names. Two pointers may have different 
names, but identify the same object. If the identity is not in the name 
itself, where is it? Suppose two different domain names are registered for 
the same web site, but the company owning those domains splits and creates 
two different web sites, one for each domain. If I have a document 
containing URIs defined with each domain, did the names used in that 
document all change when the domains were mapped to different resources?

>And remember there are many operations you can do on URIs which do not
>involve getting on the net. For example, you can look up what you know 
>about them
>from other sources. You can check your local broker for a Java implementation.
>And so on.

Are you implying that XML implementations should do this kind of research 
for such simple operations as determining the name of an element or an 

Received on Wednesday, 17 May 2000 10:37:58 UTC

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