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

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

From: Larry Masinter <masinter@attlabs.att.com>
Date: Wed, 17 May 2000 09:49:45 -0700
To: <xml-uri@w3.org>
Message-ID: <NDBBKEBDLFENBJCGFOIJEEGHCLAA.masinter@attlabs.att.com>

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

"When he uses a pronoun, she cannot tell whether he is speaking
about the same person as the other one."

Similarly, relative URIs used as namespace identifiers will
result in things that were intended to be the _same_ namespace
being recognized as different (because one was relative and the
other was absolute), and worse, having things that were intended
to be _different_ namespaces considered to be the same. These
are indeed difficult problems, but I'm not sure it is necessary
for the language designers to solve these problems. It's the
responsibility of those who issue namespace names to be careful.

In this case, appropriate caution might be "avoid using relative
URIs as namespace names" or at least to be sure that those who
issue such names are aware of the way in which recievers interpret
them.

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

No, string comparison says that two strings are equal.
In particular--and this is the crux--you can have two URI references
which are extracted from two different environments, for which

  The two strings are equal
  The two URI references identify different resources

for the simple reason that the "base", which is aquired from
the environment of the URI reference, is different.

He's dead, Jim.

Larry
Received on Wednesday, 17 May 2000 12:49:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:42 UTC