[
Lists Home |
Date Index |
Thread Index
]
- From: "David Brownell" <david-b@pacbell.net>
- To: <xml-dev@xml.org>, <xml-uri@w3.org>
- Date: Thu, 25 May 2000 14:43:07 +0200
> > This activity is a large part of what makes the relative URI discussion
so
> > 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
recs
> are inconsistent with their use of NS URI equivalence. There is currently
no
> 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
Thing
and avoid spending much time on that debate ... ;-)
***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************
|