Re: Rehash of literal-vs-relative argument status

At 6:30 PM -0400 6/19/00, Tim Berners-Lee wrote:
>  >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.

My point is, and remains, that there is not yet agreement that 
treating a namespace name as anything more than a string is 
necessary, and that in consequence, any solution that assumes 
additional semantics is going to create problems.

The details of the argument are not important. I am merely 
questioning the claim that "to compare relative URI references as 
literals is broken  as has been shown many times on this list." The 
most that you can say is "it has been argued many times on this list 
that to compare relative URI references as literals is broken."

We have as little agreement about comparison of relative URI 
references as we ever have. Deprecating, and perhaps forbidding them 
is the best way around the the _lack of agreement_ on this 
fundamental issue.

Henrik's arguments propose to broaden namespaces to the point that 
URI comparison is indeterminate whenever the URI scheme is unknown. 
This removes the problem about relative URI references, by turning it 
into a problem for all URIs. If you accept his arguments, that's good 
proof that URIs are unsuitable for namespace identification at all.


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

I would refer you to the results of the straw poll. I see no problem 
with regarding a namespace identifier as a string that happens to use 
URI syntax. In fact, I think that's the only sensible thing to do.

I think that we are being distracted form the core issues by disputes 
over philosophical scruples with few practical implications (and none 
that affect the purposes to which namespaces are currently put).


>  >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] ;-)


My point is that we currently have a decent cross-section of the 
informed and technically competent public participating in a stalled 
debate, and your arguments about URI consistency are not winning the 
day. In the IETF, were I the chair, I'd say there was rough consensus 
that relative URIs are a bad idea, that running code exists for 
literal comparison, and that it meets the goals identified for the 
namespace standard.

I'm not arguing for democracy, but I am observing that, in the battle 
of ideas, we're not converging on the view that namespaces should 
include lots of semantic baggage from URIs.

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

Right, but taking = to mean literal equality, as I take you to be 
doing, and taking ~ to mean URI equivalence as defined by a URI 
scheme, we need to define namespace equivalence, ~~.

We really want it to be clear to people what namespace equivalence 
means, and to have it be permanently defined once, and forever.

Henrik is proposing that

   u1 ~~ u2 <=> u1 ~ u2

This means that we have the implication you mention above:

>         u1 = u2  =>  R1 ~ R2

but it also means that the definition of ~ can change as new URI 
schemes are defined.

But this makes the namespace testing code very difficult to maintain.

Dan Conolly has consistently proposed that:

u1 ~~ u2 <=> absolutize(some_base, u1) = absolutize(some_base, u2)

This is a purely syntactic operation. The facts that the base can 
vary over time, and that there can be multiple relevant bases for a 
single document in a single system make this solution unattractive 
from a pure namespace point of view.

I also argue that we have seen that even developers are a bit fuzzy 
about the details of the definition of the absolutize function, and 
that it produces counter-intuitive results for URI references that 
have more leading ../'s than the base URI has path components.

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

they test URI equality after application of the absolutize function 
in a browsing context with a single well-defined base URI.

When invoking an XML processor from a command-line, the issue of 
which base to pick is a serious one.


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

none, but there is a problem with relative URI references. There is 
also a problem with Henrik's proposal, that I described above, 
perhaps more clearly than before.


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

It also is counter-intuitive in some cases, as when there are not 
enough path components in the base URI to match occurrences of ../ in 
the URI reference.


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

Maybe we're all idiots, but I don't think so. You are seeing the 
divergence between different development communities, and also that 
the internal workings of browser caches are not well-understood even 
by technically-knowledgeable web users, and standards geeks.

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

I'm attempting to understand the motivation for requiring 
retrievability of for namespace URIs, and I just don't see it as 
practically needed, or, in any case, enforceable, since many 
plausible processing scenarios won't require, and can't afford, to 
retrieve some document at the namespace.

>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 not something that is blocking progress now. There are millions 
of things that might be useful, but never turn out to be useful 
enough.
>
>But I am anxious to deprocate them untill and unless we get the
>basic architecture sorted out.

And find compelling use cases for them, and make sure that their 
availability doesn't lead to problems.

In other words, relative references have bad properties (identity 
testing) that are independent of the fact that retrieval of namespace 
URIs can't be counted on to return anything useful, or even at all.

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

Sure, and some people have come around to that idea, if I understand 
David Carlisle's recent postings.

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

Isn't this roughly a duplication of what already happened with the straw poll?

   -- 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 Tuesday, 20 June 2000 11:28:55 UTC