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

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

From: <keshlam@us.ibm.com>
Date: Mon, 22 May 2000 13:11:23 -0400
To: "Tim Berners-Lee" <timbl@w3.org>
cc: xml-uri@w3.org
Message-ID: <852568E7.005E6BE8.00@D51MTA03.pok.ibm.com>
>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.


You get the same effect with every other datatype which may be represented
as a string even though that isn't its native form.

Consider "4", "4.00", "4.0e0".

Also consider "http://a/b/./c/../d", "http://a/b/c/../d", and
"http://a/b/d". On most servers, they all retrieve the identical document,
But the URI spec agrees with string comparison and says they aren't the
same URI, and absolutizing doesn't change that.

I understand the ideal you're striving for. What we're disagreeing on is
whether the literal solution violates it... and I don't think it does, any
more than the appearance of the sample URI-reference "http:../foo" in this
paragraph does.



I'm repeating myself. Does anyone have anything _new_ to say on the topic?


______________________________________
Joe Kesselman  / IBM Research


"Tim Berners-Lee" <timbl@w3.org> on 05/17/2000 03:14:16 AM

To:   Joseph Kesselman/Watson/IBM@IBMUS, <xml-uri@w3.org>
cc:   <xml-uri@w3.org>
Subject:  Re: Are *relative* URIs as namespace nemes considered harmful?




-----Original Message-----
From: keshlam@us.ibm.com <keshlam@us.ibm.com>
To: xml-uri@w3.org <xml-uri@w3.org>
Cc: xml-uri@w3.org <xml-uri@w3.org>
Date: Tuesday, May 16, 2000 4:53 PM
Subject: Re: Are *relative* URIs as namespace nemes considered harmful?


>>> This is why many of us voted for the Literal String solution. It gives
>us a
>>> version that permits the reliable recognizability promised by
>Namespaces,
>>> _and_ permits relative syntax for those who want that option. The
>>> alternatives all seem to break one community or the other.
>>
>>However, it creates an exception to the usual rules of URI-reference
>>interpretation.
>
>Only if you insist that the Namespace Name is in fact a URI-reference. If
>we accept that it is a string which is _formatted_ as a URI reference --
in
>other words, that it only becomes a reference when you actively attempt to
>use it as one by combining it with a base address -- there really
shouldn't
>be a problem.


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.

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.

The XML specs have to go one way or the other: commitment to or separation
from URIs.
Received on Monday, 22 May 2000 13:11:49 UTC

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