W3C home > Mailing lists > Public > www-tag@w3.org > December 2002

Equivalence and multiple-role URIs (WAS: Posted draft of URI comparison finding)

From: Miles Sabin <miles@milessabin.com>
Date: Tue, 3 Dec 2002 11:32:18 +0000
To: www-tag@w3.org
Message-Id: <200212031132.18063.miles@milessabin.com>

Larry Masinter wrote,
> I think at the root of many of the difficulties in this discussion is
> what seems like an assumption that there is (or should be) only one
> notion of "equivalence" for URIs.
>
> But among the set of all possible strings (sequences of characters),
> there are many different equivalence relationships.
<snip/>

I think this is exactly right.

> And it would be helpful for applications that use a fine granularity
> equivalence relationship to avoid the situation where two identifiers
> that are equivalent under some relationships are used differently,
> e.g., mandate that once a namespace name is assigned, no other string,
> equivalent under coarser rules, should also be used as a namespace
> name.

This too.

To spell it out a bit more, the problem here is that we have the same 
string functioning in two roles (as a namespace identifier, as a 
resource identifier), where each role implies a different equivalence 
relation.

To illustrate,

  <foo:wibble xmlns:foo="http://a/b/c/%7A"
              xmlns:bar="http://a:80/x/../b/c/%7a">
  </foo:wibble>

Applying the current namespace identifier equivalence relation, foo and 
bar are distinct namespaces. However, applying the RFC 2396/2616 rules 
the two are equivalent and an attempt to retrieve a namespace document 
will have the same result in both cases. If the two namespaces really 
are distinct that seems wrong.

So if namespace identifiers _are_ to be used for the retrieval of 
namespace documents there doesn't seem to be much option but to use RFC 
2396 + scheme-specific rules for the namespace identifier equivalence 
relation too ... which would be unfortunate IMO.

Cheers,


Miles
Received on Tuesday, 3 December 2002 06:32:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:14 GMT