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

Re: Fwd: I-D ACTION:draft-daigle-uri-std-00.txt

From: John Aldridge <john.aldridge@informatix.co.uk>
Date: Thu, 07 Sep 2000 16:14:59 +0100
Message-Id: <>
To: michaelm@netsol.com
Cc: "Simon St.Laurent" <simonstl@simonstl.com>, xml-uri@w3.org
At 10:21 07/09/00 -0400, Michael Mealling wrote:
>On Thu, Sep 07, 2000 at 02:51:39PM +0100, John Aldridge wrote:
> > I'm quite happy with resources being a flexible, extensible concept.  I'm
> > also happy with the name of a resource being a URI.  I understand, and I'm
> > comfortable with the fact that the entity body associated with the 
> resource
> > may change from time to time; and that two distinct resources may, in 
> fact,
> > have the same associated entity body.
> >
> > What I'm not happy with is that there is no widespread agreement on how I
> > tell whether two URIs name the same resource or not.
>There are really two answers to this and I'm afraid your not going to like
>either of them:

On the contrary, I do like these answers...

>Resource: any abstract concept which is identified by a URI
>URI:      a unique string that is bound in a 1:1 relationship with a Resource

>lexical equivalence: the act of comparing two URIs to see if they are
>           syntactically identical and thus, by the first two definitions,
>           identify the same Resource.

So, as I understand what you've said, two URIs identify the same resource 
if those URIs are byte-for-byte identical.

I've snipped stuff which says that distinct resources may, in fact, be 
functionally equivalent for various purposes.  Absolutely agreed.

Do you also agree with the following:

Do you go further and say that  XSLT (which matches elements and attributes 
based on their namespaces being the same) must therefore use this 
definition of equivalence?  I.e. two QNames match if their namespace URIs 
are byte-for-byte identical and their local parts are the same?

Again, I agree, but Henrik Frystyk Nielsen (at least) has expressed the 
view that this is not what the relevant RFCs/RECs say (or what they should 
Received on Thursday, 7 September 2000 11:16:30 UTC

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