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: Thursday, June 15, 2000 4:18 PM
Subject: Re:


>>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".
>
>Uhm... I don't quite understand why. The aliasing scenario you pose only
>exists if aliasing is designed into the system -- as it is for URIs, but
>isn't for literal strings. Which is the point I was making; URIs have
>characteristics that we don't want for this application, as well as ones we
>might.


On the contrary, exactly the same applies for your literal strings,
its just that there is no social setup around allocating them.
Example:  You define "joe1" as being a namespace.
I define "tim1" as being a namespace whoch while
having a difefrent identifier is in absolutely all other respects to
be takes as being equivalent to your "joe1".

We have formally distinct namespaces which in fact are as
equivalent in practice as you like.
It is nothing to do with URIs.
In both  cases we can all work and do our jobs using
string comparison (of the string or URI respectively).
I don't regard this as a problem.
I was just knoing the goal of "establishing that two namespaces
are different" off its pedestal of referring to some inherent
form of equivalence apart from its definitive form of equivalence:
identifier equality.


>>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 so declare it. But unless there's some mechanism for globally
>asserting that -- which there isn't, in the namespace spec as written --
>your declaration has no effect. Code that looks for X isn't going to
>magically recognize Y as the same namespace, and shouldn't.


That's not true. Without a global metod for asserting it,
a private communication (maybe built into th code)
might let it know of the equivalence and therefore dispatch
a Y document to an X processor.  You can't stop people doing
that, even though the specs we are talking about don't say how to do it.

>The problem is: URIs aren't defined to behave that way. URIs say that you
>can only say that X equals X; you can't say the X does not equal Y, only
>that you don't know. And "I didn't know" is a bad basis for most decisions.


Depending in what you mean by "equals". If you mean "the same namespace"
then that would mean "the same URI". So you can say absolutely.

>Yes, we can impose an additional rule, for namespaces only, about
>"definitive URIs"l. But I don't see that this is any less an affront to
>URIs than the suggestion that relative references be forbidden in this
>context, or even that the strings be taken as literals.

The difference is that it doesn't make the system inconsitent - it matches
what most caches do with URIs all the time in allowing string
comparison of URIs.

>It's still a matter
>of taking the URI syntax an applying a custom interpretation.


No - to compare reelative URI references as literals is broken
as has been shown many times on this list.
Defining a particular URI as being the definitive reference to
a namespace does not break anything.

>>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.
>
>Absolutely. It works today because XSLT is operating in Literal mode.When
>we declare that these are URIs and folks start carrying over expectations
>from other uses of URIs, I'm not sure that the results will still be
>"expected".

It will be a lot more expected than the idea that "./foo" and "foo"
represent
different things, when you start carrying over expectations from other
uses of URIs.

But you know - I really don't expet a whole lot of failues from this
misunderstanding. I don't expect the distinction between
http://ww.w3.org/200/a and http://WWW.w3.org/2000/a to be
made to delibertaely distinuish two namespaces.

I agree that there will have to be a warning to the extent that
XSLT (like sed) when looking for one won't find the other.
But I see this (literal comparison of URIs) as being the least
confusing criterion for comparison.

[...]
>Joe Kesselman  / IBM Research


Tim BL

Received on Monday, 19 June 2000 13:47:34 UTC