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

Re: Irony heaped on irony

From: David Brownell <david-b@pacbell.net>
Date: Thu, 25 May 2000 14:43:07 +0200
Message-ID: <000601bfc647$40311780$19e581c2@brownell.org>
To: <xml-dev@xml.org>, <xml-uri@w3.org>
> > This activity is a large part of what makes the relative URI discussion
> > ugly, because the results of that are intertwined with the
> > NSURI-pointing-to-schemas issue.
> That is a red herring IMHO. The issue is that Namespace, XPath, and DOM
> are inconsistent with their use of NS URI equivalence. There is currently
> rec stating what an application can or can't do with a namespace URI.

Well, there IS a specification (the URI document) that talks about
relative URIs ... it's not a W3C document, it's an IETF one.

It's likely worth referring to much more, but there's certainly an issue
about whether it's ever a reasonable thing to compare relative URIs that
don't have the same context/landmark/base/root/... (lots of naming terms
for that particular concept).

It appears that some folk have assumed -- very wrongly IMHO -- that it's
possible to compare the URI "foo" (base:  http://www.example.com/bar)
to the URI "foo" (base:  http://www.example.com/bar/ with terminal slash)
and come up with them being the same URI ... clearly wrong.  (".../foo"
in the former case, ".../bar/foo" in the latter.)

Issues about "%NN" escaping crop up too, but again it's clear (IMHO) that
such escaping is for encodings of the URIs, not to the URIs themselves.
So again, comparing URIs must remove such escapes.

> ... Leave the packaging and dereferencing
> out of it for now.

It also appears that some folk have decided to use the namespace comparison
bug (above) as a tool to restart that dereferencing debate.  That really
doesn't help lead to resolutions.

- Dave

p.s. Since I'm on the road, that makes it easier for me to do the Right
    and avoid spending much time on that debate ... ;-)
Received on Thursday, 25 May 2000 08:45:37 UTC

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