Re:

-----Original Message-----
From: keshlam@us.ibm.com <keshlam@us.ibm.com>
To: Tim Berners-Lee <timbl@w3.org>
Cc: "Clark C. Evans" <cce@clarkevans.com>; xml-uri@w3.org <xml-uri@w3.org>
Date: Monday, June 12, 2000 9:07 AM
Subject: Re:


>> On the contrary, you can indeed acertain that
>>two URIs given identify the same resource.
>>What you cannot do is acertain that they don't.
>
>Was there a clear defense of the assertion that this weak inequality was a
>reasonable characteristic for namespace identities, and thus that using
>URIs for this purpose really made sense in the first place?


I argued it at some length some days ago, but I am not sure that
I could find it easily!  I augued that you can never hope in a scalable
system to know from a name that something is "different".

This is because someone can give an arbitrary name to
something you have already named.  That is life.
So if you make a namespace http://us.ibm.com/~keshlam/X
I can make a http://www.w3.org/2000/Y and declare it
to be for all purposes equivalent to your X.
You can't stop me.  So in that sense it is useless to argue
that any real thing will ever get only one name.

But Larry made a good point that it was simple to make URIs
which have this property - you can define a type of equivalence
which uses the concept of a definitive URI for
a namespace.  This is the one which is mentioned both in
the spec and the schema.  The "is the definitive URI of"
relation gives you exactly that strong equivalence.


>I think there _is_ an expectation that we can clearly distinguish namespace
>inequality as well as equality. Consider XSLT processing; elements
>belonging to XSLT's namespace are commands, those which don't are
>considered literal content. It feels rather strange to be considering
>recasting this as "those we are/aren't sure of".


It has to be clear that an XSLT template will pick out
only those elements whose namespaces have exactly the
given URI.  I think that is what people expect, and it works.

>______________________________________
>Joe Kesselman  / IBM Research


Tim BL

Received on Thursday, 15 June 2000 10:19:05 UTC