(no subject)

At 1:47 PM -0400 6/19/00, Tim Berners-Lee wrote:
>No - to compare reelative URI references as literals is broken
>as has been shown many times on this list.

This is not true. It has been as frequently denied that this is 
broken as it has been asserted that it is broken. This fundamental 
disagreement continues. I venture to guess that in a vote literal 
comparison would still win, simply because of people's desire that 
the spec not be amended without a version change.
>Defining a particular URI as being the definitive reference to
>a namespace does not break anything.

No, that's the point of literal comparison.\


>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.


Depending on the base, they _do_ represent different things. 
Specifically, in the case of a base that is the null string.

>
>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.

This kind of inequality is a core fact about URIs, as defined, 
because an unknown scheme may impose additional arbitrary equivalence 
rules in addition to literal equality. This isn't a practical problem 
for hypertext linking, as equality testing is only important to 
system implementors building caches for efficiency reasons.

For namespaces we have authors and other end-users for whom 
equivalence testing is the _most_ important function: they want to be 
able to create references that will refer _dependably_ to the 
"definitive reference to a namespace" that you mention above. Literal 
equality is a much simpler rule to define and to check. The 
"absolutization" algorithm is hidden deeply enough in the systems 
that users work with every day that many details about it are obscure.

Just as a good XML DTD will not use a tag <PARA> to enclose 
paraphrases, and <para> to enclose paragraphs, people will avoid 
intentionally using case distinctions in a confusing way. Having a 
simple comparison rule will make namespace detection much clearer.

>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.

Exactly, and this argument also goes through for relative URI 
references as well. If the developers on this list have required 
handholding and poking thought the RFCs to get the details of this 
process down, the algorithm is clearly not widely understood. It is 
widely implemented, but for the task at hand for namespaces, it must 
not just be implemented, but understood clearly by any user of 
namespaces, as the function they are trying to accomplish is one of 
enabling unambiguous matching of fixed names.

You clearly feel strongly about relative URI references because you 
believe that namespaces should have been more ambitious, but their 
purpose is clearly established and can't be changed instantly without 
doing damage to the standards process and the W3C.

We still have to go with forbid, or deprecate (with literal 
comparison), or perhaps deprecation followed by forbidding. The last 
choice could potentially be succeeded by a fully specified namespaces 
2.0 that re-introduces the syntax in a rational way, if it is 
actually needed.

Personally I think the "semantic web" doesn't _need_ relative 
namespace specification, but that's a matter of opinion.

I must say that I'm not seeing much progress in this discussion, 
except in filling my hard disk.

    -- David
-- 
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
http://cs-people.bu.edu//dgd/             \  Chief Technical Officer
     Graduate Student no more!              \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
                                              \__________________________

Received on Monday, 19 June 2000 16:19:20 UTC