Rehash of literal-vs-relative argument status

-----Original Message-----
From: David G. Durand <david@dynamicdiagrams.com>
To: xml-uri@w3.org <xml-uri@w3.org>
Date: Monday, June 19, 2000 4:19 PM
Subject: Re:


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

Leaving aside numbers of times something is said, there was an argument.

First, there was an argument that a system could not
simultaneously treat a relative URI reference as such (absolutizing it)
and treating it with literals because if the test cases ("foo", "./foo" in
one directory and "foo" and "foo"in different directories) which gave
incosistent results.

The response to that was were two directions.  One was in the direction
that namesapces were not resources anyway, which means that
we are not really talking about relative URI references at all.
Maybe that is the sense you mean - that something with the
syntactic propoerties of a URI-reference but none of the semnatics
can be compared as a string.

The other was to suggest that the two conflicting forms of identity
could be used by different layers.  There was a proposal that
XSLT should be layer-separated from underlying namespace handling,
Michael Champion in reversing his opinion
http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0575.html
I thought gave a convincing explanation of why it would not work,
and indeed I pointed out in
http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0597.html
that the same argument can be applied for whatever else
you are tempted to put into an upper layer.


>This fundamental  disagreement continues.

The fundamental debtes I did not think were whether one can
consistently regard a URI refernece as a string.

>I venture to guess that in a vote literal
>comparison would still win,

Wherever did this idea of voting come from?  A straw poll is a good way
of seeing where a likely direction might be in the search for unanimity,
A vote is aterrible way of making standards.   It leads to political
lobbying
but not necessarily to a thorough analysis of the question, or to the
technically optimum result.  Its advantage is it guarantees progress to a
deadline.
(Any discussion to a different thread please!). We don't count votes - we
count ideas.[sm] ;-)

>simply because of people's desire that
>the spec not be amended without a version change.

When there is such inconsistency and incompatability, lack of change
seems to argue against stability  rather than for it.  I am not convinced
that

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

Be more specific.  There may be forms of equality of resource  ~
and forms of string munging function munge() for which in a given
new scheme

   munge(u1)  = u2   =>  R1  ~ R2

where = is string comparison, and u1 identifies R1 and u2 identifies R2.

No new URI schem can break the rule

        u1 = u2  =>  R1 ~ R2  for and equivalence ~

or as we say

      u1 = u2  =>  R1 = R2

> This isn't a practical problem
>for hypertext linking, as equality testing is only important to
>system implementors building caches for efficiency reasons.


These systems test URI equality and  from it deduce
resource equivalnce, and return an equivalent resource
without having to ask again.

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

Ok, so you are happy with using URIs.

> Literal
>equality is a much simpler rule to define and to check.

So just use absolute URIs, and compare them literally and where
is the problem?

> The
>"absolutization" algorithm is hidden deeply enough in the systems
>that users work with every day that many details about it are obscure.


It is a string function of two strings.  It is older and more deployed than
XML.
It is based on the unix algorithm you use almost every unix command line.
Give me a greak.  It was designe sepcfically to capture the common cases
users are used to.

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

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

(on this list)

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


Yes, you have suggested that before and I think it is possible.

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


Please don't pin this on the smentic web - we need namespaces
to work for any application.

Probably the smentci web si  where you will fidn the people
who assume that you can define a laguage in a document
and use it in the same document, and that this shoul;d be
possible by self-reference without having to change the documnet
so that it can refer to iteslf by name.

But I gave a living database example which was much more down to
earth.

But I am anxious to deprocate them untill and unless we get the
basic architecture sorted out.


>The more important thing everyu
>I must say that I'm not seeing much progress in this discussion,
>except in filling my hard disk.


A pity you didn't notice3 a few people dropping the idea that you
could use relative URIs as relative URIs and also use them as strings
in the same system.  There has been more progress too. but
I do worry that it will never end.

We may have to break  the deiscussion into the preparation of
two (or more?) different but consistent proposals and elaboratethem
separately
and then have some kind of a wide review at AC level I suppose. (or two
languages).
That is the sort of way I casn see this deadlock being broken.

Tim

>    -- 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 18:29:04 UTC