Re: A new proposal (was: Re: which layer for URI processing?)

-----Original Message-----
From: Jonathan Borden <jborden@mediaone.net>
To: xml-uri@w3.org <xml-uri@w3.org>
Date: Thursday, May 25, 2000 12:23 AM
Subject: RE: A new proposal (was: Re: which layer for URI processing?)


>Tim Berners-Lee wrote:
>...
>>
>> No, this is not such an example.  The chemical plant did not
>> blow up because of a "fragile" base URI.  It blew up because the
>> base URI which was clear to all parties was not used to absolutize the
>> relative URI. It blew up because the definitions of idenity to the "upper
>> layers" and the "lower layers" were different.  It refutes the
>> argument that
>> the comparisons can be done differently by different layers.
>
>But as Paul Grosso notes, the URIs:
>
>http://example.com/./detonator and
>http://example.com/detonator
>
>will typically refer to the same resource despite the fact that the 2 URIs
>are not identical, so the fact that a relative URI is 'absolutized' on the
>client or an absolute URI is normalized on a server doesn't change the fact
>that there is a binding process which associates a URI with a resource.
>
>To take this to its logical conclusion, if you are to require relative NS
>absolutization, you ought then require absolute URI normalization ... and
>will need to define server behavior in order to make this work.
>
>This problem it seems is an intrinsic problem with URIs as defined.
>
>Actually it goes further than that:
>
>Suppose the DNS entries for example.com and another.com point to the same
IP
>address, in this case
>http://another.com/detonator is just as dangerous.
>
>You would need to define a normalization process that performs a DNS lookup
>as well... But suppose the server at the URI http://yetAnother.com/flower
>redirects to http://example.com/detonator ... and on and on ... in reality
>this is a difficult problem and it seems can only be solved by an
>understanding of the semantics of the particular URI.
>
>Is there a class of problems caused by relative URIs that isn't also caused
>by un-normalized URIs?


Your comment is absolutely right.   My example was wrong.
There is such a class but I didn't give you a member of it.

In the example I complained that the XMLT script did not recognize
a namespace when it was the one it was looking for. This can
as you say happen fo many reasons.  (Think of an xhtml processor
which finds and ISO XHTML namespace, necause ISO acyually
copied W3C's specs and republished it with their own name, say).

In other words

               u1  !=  u2     =!=>  R1  not equivalent   R2       ......
(life)

URI difference does not imply resource non equivalence for any particular
purpose.
Jonathan gives lots of examples above.

However, the important identity we do have is

                u1 = u2      ==>    R1  equivalent R2          (URI
identity)

The example which breaks this is when the XSLT script is explcitly asked to
look out
for a safe namespace,    "http://example.org/light"   which turns on the
lights.
The document on http://example.com/foo.xml contains a refernce to
http://example.com/light"  which lights the fuse on the detonator.  The
XSLT script had ascertained that it *did* know what the document meant,
but the upper layer forms the absolutized URI and then it turns out to mean
something different.

True, if you thought you didn't understand something which really you could
with extra knowledge, nothing as broken.  If you think you do understand
something
but it really meant something else, the system is broken.

So I still maintain that realtive URIs and absolutized URIs don't mix,
and no "level" argment will work unless there is nothing which
uses namespace identity in the lower level.

Excuse me, I got the example wrong.  Thank you Jonathan for pointing that
out.

The adjusted example, however stands.

>Jonathan Borden


Tim BL
>

Received on Thursday, 25 May 2000 19:32:07 UTC