Re: uri-comp draft necessary?

I think that a namespace document would unambiguously carry the identifier
for the namespace that it talks about, but one could locate that document
in a number of different places. Making the deployed infrastructure change
is unrealistic, and requiring that a resource is accessable from only one
location is an unnatural act.

To me, this highlights the need to be very clear when speaking about the
context of a UR*; URIs and URLs are different; not because of any
syntactic or observable difference in the UR* itself, but because of the
context it's being used in. I.e., you can use 'http://www.example.org/' as
both a URI and as a URL; in each context it has very different properties.

BTW, it was asserted that all five of these could be cached under one or
two entries. Actually, they'd be cached by most implementations as four;
the only ones that are the same from a cache's view of URI comparison are
the second and third.

Correct implementations wouldn't be able to do better than that without
authoritative equivalence information from the origin server; this might
take the form of out-of-band assertions (in RDF, etc.) about the URI space
under a particular authority.



----- Original Message -----
From: "Miles Sabin" <miles@milessabin.com>
To: "WWW-Tag" <www-tag@w3.org>
Sent: Wednesday, December 18, 2002 11:06 AM
Subject: Re: uri-comp draft necessary?


>
> Paul Prescod wrote,
> > These URIs all deliver the same data:
> >
> > http://www.microsoft.com/presspass
> > http://www.microsoft.com/presspass/
> > http://www.MICROSOFT.com/presspass/
> > http://www.microsoft.com/PRESSPASS/
> > http://www.microsoft.com/presspass/default.asp
>
> Right, but this document uses five distinct namespaces,
>
>   <ns1:a
>     xmlns:ns1="http://www.microsoft.com/presspass"
>     xmlns:ns2="http://www.microsoft.com/presspass/"
>     xmlns:ns3="http://www.MICROSOFT.com/presspass/"
>     xmlns:ns4="http://www.microsoft.com/PRESSPASS/"
>     xmlns:ns5="http://www.microsoft.com/presspass/default.asp">
>     <ns2:b/>
>     <ns3:c/>
>     <ns4:d/>
>     <ns5:e/>
>   </ns1:a>
>
> This is a problem if you expect to be able to use namespace identifiers
> to retrieve namespace documents. On retrieval RFC 2396/deployed network
> infrastructure equivalences are in play, so if you don't want the
> namespace documents of distinct namespaces to collide, you have to
> choose your namespace identifiers so that as well as being non-
> equivalent wrt the Namespaces REC, they're also non-equivalent wrt RFC
> 2396/deployed network infrastructure.
>
> I would assume that if the TAG decides to endorse namespace documents of
> some sort it would have to recommend that restricted choice of
> namespace identifier as a best practice. If you wanted to follow that
> best practice you'd have no option but to assign namespace identifiers
> as if the equivalence relation were RFC 2396, no matter what the
> Namespaces REC says.
>
> That's rewriting the REC by the back door IMO ...
>
> Cheers,
>
>
> Miles
>

Received on Wednesday, 18 December 2002 16:03:49 UTC