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: Saturday, June 03, 2000 5:56 PM
Subject: Re: on relative URI references


>
>
>> 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.
>>
>That isn't how it works.

What do you mean, it isn't how it works?.

I gave an example in which the application layer tries to set
an attribute and the DOM refuses.  For the application, the namespace
identify is the absolutized form, and for the DOM, it is literal
comparison. The DOM won't allow two of the "same" attribute on
an element. For the application,. they are not the same, and indeed
it really needs to construct a document -- asn a serialization of  the
state of some object -- which has both atributes present.
I have shown that hte system will fail, the DOM will return an error.
What do you mean, "that isn't how it works"?
That isn't how your software works?

>If an application is retrieving resources based on the namespace name
>then it has to take the namepace name and make an absolute URI
>A namespace name is, by definition, a URI reference, so in the case of
>relative uris the same cautions apply to both. The uri reference
><a href="foo.html"/> will refer to different resources depending on
>context The same happens for namespaces, but that isn't broken it's
>just the way it works (currently).

Not for the nemspace spec.

> Your stylesheets were written on
>the assumption that if the namespace name was the same, the referenced
>resource would be the same, this of course is not true in the literal
>interpretation but, as for href links, the solution (if you want to
>ensure that you get the same resource) is to ensure you use the same
>base URI. XSL makes that particularly easy to do but your stylesheets
>did not do that.


(I have lost track of which style sheets of mine we were discussing.)
These were stylesheets which reefered to a namespace using a relative URI,
I guess. XSL allows you to absolutize things explicitly, you say, so I
should
not have been using relative URIs.  The purpose was to show that when
you use realtive URIs things break if you trying this "layering" idea.
You say so I shouldn't have used them in the example. Well, I shouldn't
because they break. Which I guess was the point I was trying to make.


>> If you want to actually refer to the resource and see whether the
>> linsk are to the same resource, you need to absolutize.
>Yes XSLT allows you to ignore the base URI of the document and make
>absolute with respect to any base URI, so I can't see why you can't
>do that for namespaces. That is to retrieve the resource identified
>by the namespace name of the current node do
>document(namespace-uri(.),document('http://some/fixed/base/uri'))
>would do as I suggested, always make the namespace name absolute
>using some fixed base, and retrieve the resource, why is this
>`against the uri spec' If it is such a simple application of xsl?


The URI spec specifies that a relative URI is relative to the URI
of the containing document.  That's what it means.

>> maybe we should change that if it seen as being a personal
>> endosement.
>
>It most definitely is seen that way.  Actually I do acknowledge that
>you have done a lot to try to open up w3c, but the text of the
>recommendations and parts of the overall w3c constitution do
>give the impression to outsiders that the whole thing is just your
>personal fiefdom.


Sigh.... the frustrating thing is being accused of having the personal
fiefdom by people who do not know better but not in fact having the
power to dictate the course of the future!    ;-)

>> Actually I would prefer doing it right, absolutizing them.
>I do wish you would acknowledge that there are at least some problems
>in having element names of a document being context sensitive and
>becoming undefined if you read a document from standard in.
>I would say that it was completely unworkable.

A completely acknowledge that using a relative URI-reference
is a really unwise thing to do in the vast majority of cases.
In all the cases which you can consider, clearly, it is indeed
completely unworkable.

What amazed me was that people did it.

It amazed me that people [say they have] used "foo.html" as a namesapce
name -- and assume it to have some global validity.
For me, I would never do that, and for the milllions of people who actually
use relative URIs all the time I would expect them never to do it.
I am amzed that people do -- but of course now I am wiser because I have
found that that there is a subculture here of people who based on the
character by character comparison wording in the NS spec would actually
use a string such as "foo.html" without thinking that its meaning be context
sensitive.

Of course this creates big problems. I absolutely acknowledge it.

It is  so easy when you are offline to make a namesapce URI-reference like
"/play/tim-234"
which will work all over the same computer.

However, I have repreatedly asked for examples in real life on the web
where this has been done in ways which would break if in fact the
name were to be asbolutized, to be response, so we must conclude that
these have been thought experiments, or applictaions in whcih one document
is processed at a time and therefore the question of what the actual
namespace name really was turned out to be irrelevant.

> I don't expect you to
>go that far, but some hint that the absolute interpretation would
>make most existing uses of XML documents impossible (for documents
>using relative URI namespace names)

David, this was the key to the earlier misunderstanding.  I think you mean
"for documents abusing relative URI namespace names".
Correct me if I am wrong, but we are talking about documents which use
exactly the same string as a relative URI-reference in two documents
in different directories in a file system (say) and expect them to mean
the same thing.  Yes, these would be the problem cases of course.

What existing uses of XML documents are you actually talking about? Can you
give me a pointer?

>would help the discussion along.


On your side, I would like you , if you can, to envisage the database
application
which produces a virtual namespace for every database file, and when it
exports
the result onto the web finds that, because it runs as a serverlet, it can
only
define things in the local URI space, and therefore finds a relative
URIreference
the only thing it can use to identify a namespace.
If you could admit that there was at least one situation where, if relative
URI referencess
were treated according to the URI spec instead of the namespace spec, that
it would be useful and valid and stable?  This is like the situation of a
virtual
hypertext page (like a map) in which a relative URI-refernce links the
surrounding HTML and the
embedded image.

(In fact, my stance at the moment is that relative URIs should be banned as
there is
alas this mix of interpretations)

Tim
>
>
>David
>

Received on Tuesday, 6 June 2000 10:59:28 UTC