Re: on relative URI references

-----Original Message-----
From: David Carlisle <david@dcarlisle.demon.co.uk>
To: timbl@w3.org <timbl@w3.org>
Cc: xml-uri@w3.org <xml-uri@w3.org>
Date: Friday, June 02, 2000 1:20 PM
Subject: on relative URI references


>
>> And indeed the semantic sof the document are unchanged.
>> What is changes is what happens if you break the assumption
>> under which the shorthand was used.
>
>Saying that someone who uses a relative href has some specific
>location in mind for the HTML page they are writing and "assumes" it
>won't ever be moved is a really strange way of describing the process.


I think we both understand the process.  If my attempts to argue that
the process works and is understood -- and therefore that abuse of it
in namespaces is unlikely -- sounds strange I am sorry.
When I make a relative href which I do every time I write hypertext
documents and save them, I don't think of the URI of say an included
image as a location, but as a name.   We have rules on the site
which we have found make life easiest given the strange things we do inside
the website. The rules and assumptions will of course be different for
different
people.  But there are millions of people making their "home pages" and
uploading their images into "../images" and refering to them relatively
there.

Theydon't assume it will never be moved. They assume they will have to deal
with
it is the relationship between the URIs is broken.

>If it were anyone else I'd just say the description was simply wrong,
>but seeing as it's you and URI are your baby, I suppose I will have to
>defer.


Don't defer. no one else does ;-)

>> And the resulting links are to new resources,
>> not to the old ones, so there was no identity preserved.
>
>I do however have no problem agreeing with that..
>
>> I have tried in many ways top give specific examples (Database...)
>> of things which actually break when this is done.
>
>But they have all involved broken stylesheets.


What do you mean, "broken?"  I suppose I will have to find the assumptions
under which you can define them as broken...

>> One counterexample  would be for example that the DOM would refuse to
allow
>> an attribute to be set on the basis that it was "the same namespace"
>> although for the application it was not, as the absolute URI was
different.
>
>It is up to the namespace spec to describe conforming documents and
>which attributes are the same, an application layered over that
>just has to use that information (or to put it another way just has to
>use the information John C et al provide in the infoset)


Application: Set attribute x:a to "red"
Infoset: "No, i can't you already have that same attrubute"
Application: "No, I have a y:a attribute and that is all. Please do as I
asked"
Infoset: "But x: and y: are the same namespace"
Application:  "Oh no they aren't"
Infoset: "Oh yes they are!"
Application: "Are not!"
Infoset: "Are too!"

So tell me how the infoset/dom and the application are layered.
As Clark said, 'that doesn't work.

>> The DOM currently handles oinly one docuemnt at a time, but XSLT
>> handles two (script and input).  Later systems will handle many more at a
>> time,
>> so the problem will actually arise in real cases.
>
>XSL document() function means that XSL already can deal with many
>documents at once (and a single document may involve entities at
>different base URI) which reminds me you didn't explain why
>comparing two relative URI from href attributes as strings using xsl
>document() doesn't break web architecture.


It doesn't break web architecture so long as you realize you
are only testing the value of an XML attribute, and not the identifier of
a linked document.   If you want to actually refer to the resource and see
whether
the linsk are to the sme resource, you need to absolutize.
The namesapce needs to refe to the resource - the href attribute value
by itself has no semantic value.

You could layer these things *except* that the infoset layer needs to
compare namespaces.

>> Our own recommendation. A lot of people worked on it
>
>Yes I realise that a lot of people work on w3c specs, but the text of
>every recommendation makes it explicit that it is endorsed "by the
>director"

maybe we should change that if it seen as being a personal endosement.
(I would specifically like to remove it from the stylesheet PI!)  ;-)

>as a recommendation which means that there are special
>procedural problems if you (rather than anyone else) decide at some
>later date that you no longer like a recommendation.


We have moved on from a lot of specs.  HTML 2.0, HTML 3.2, ...

We have to decide we don't like one of these inconsistent specs.

>> Many people have propoes on this list and others deprocating relative
>> URIs for namespaces. If you do that then string comparison can be
>> done with or without absolutizing.
>
>No. Deprecate means allow but warn against (and I have no problem with
>that) but that means that you still have to specify what to do in that
>case. You can only avoid deciding if you chose the forbid option.

>> 1. It is against the URI spec.
>
>Almost everything has been claimed to be against the URI spec or
>against web archetecture at some point in the debate. The RFC is
>relatively relaxed about where the base URI comes from, I can't see
>why namespace processing can't specify a fixed base.

>
>Is XSLT document() function against the URI spec?
>
>This allows a URI reference to be extracted from some document and
>dereferenced with respect to any base URI whatsoever (by supplying the
>base in a second argument). The behaviour of your `shorthand'
><a href="foo.html"> and the full
><a href="http://www.example.com/foo.html">
>is completely different if the XSLT expression is
>document(@href,document('http://www.example.org'))
>The relative foo.html, although it is in an html file at example.com
>will be resolved relative to the example.org base URI by XSLT.
>This hasn't involved moving the source document it is just yet another
>example where the relative URI reference is not treated in the same
>way as the `equivalent' absolute URI.
>
>> 2. It actually messes up people who wnt to use them really as
>> relative URIs.
>
>It doesn't mess them up half as much as the forbid option that you
>seem to prefer.


<correction>
Actually I would prefer doing it right, absolutizing them.
Treating them like any other URI-ref in any other document.
But there are a lot of people on this list who maintain
for one reason or another that they have to compare them as strings, and
so we may be forced to leave the next 10 years of development based on
a rather messy platform for which posterity will not thank us but don't mark
it
as my preference.
</correction>

>> I don't think we have  seen any real live examples of
>> relative URI use for namespaces at all -- it is just software.
>
>Everything (here) is just software (I'm not sure I inderstand this comment)


Most people say here that documents are important and must live forfever
but software can change. So I have not seen examples of documents
(serious, real documents) which break if we absolutize. There may be
millions
but I haven't seen one.

>
>David
>

Received on Saturday, 3 June 2000 00:34:55 UTC