Re: Injective Quality (Was: Re: URIs quack like a duck)

-----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: Thursday, June 01, 2000 6:47 PM
Subject: Re: Injective Quality (Was: Re: URIs quack like a duck)


>
>[a couple of replies to specific points, the contents of which
>you can probably guess by now:-), but a more constructive suggestion
>at the end]
>
>
>> Relative URI references are not URIs.  They are only shorthand forms
>> for URIs which assume the writer and reader are both aware of the URI
>> of the context.
>
>HTML files can be moved,

Therin lies perhaps the assumption I am not willingto make.
In general, if you mean publish a set of bits from one HTML file at another
URI, then they can't.

>if relative URIs were merely a shorthand then
>one would expect that the semantics would be unchanged if I replaced
>the shorthand by the equivalent absolute URI.

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.

>But as you (of all
>people!) know, that isn't true. <a href="foo.html"> refers to whatever
>resource is located by the URI obtained by combining the relative URI
>with whatever base URI is current, which may not be known to the
>author of the document
> (this after all is why relative uri references
>are so popular, you can make up a zip file of interrelated files and
>wherever anyone unzips them, they'll still work as intended, even
>though the context of the author is completely different to the
>contexts of the readers.


It happens that the relative URI-references have the property of
invariance under the opeartion of making a copy in a new space
of a set of resources which only have links between them.
And I agree that people use that a whole lot.  But that is a very
specific operation. And the resulting links are to new resources,
not to the old ones, so there was no identity preserved.

>> But still remember that "./foo" and "foo" mean the same thing.
>
>./foo and foo are two different relative URI references which,
>given a base URI, will always produce the same absolute URI.
>Being two different URI references means that they can be used
>as two different namespace names, seeing as namespace names
>are defined to be URI references.
>
>I accept that you don't approve of that use, but I don't accept that
>the use is any way inconsistent or unworkable.


I have tried in many ways top give specific examples (Database...)
of things which actually break when this is done.
Maybe this needs a paper written.
But there are lots of examples in the archive. The only place
the lower layer uses identity is in attribute checking,
or (sdepending on the layer boundary) XPath & therefore XSLT.

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.
That is the problem with layering.

Another is the example I gave with XSLT selecting the wrong elements.

At the design level, the DOM has to decide (and the whole working group
is held up since many weeks waiting for the resolution of this precise
issue)
whether to internally reprtesent the namepsace in raw string or absolutized
form.   It the latter, to be compatible with Xpath (and for example to allow
XPath applications to be built on top of the DOM) it has to change
some of the factory methods to allow a read-only base URI to be quoted
when a DOM tree is created.

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.

(The thread about attribute checking noted correctly that XML did not have
the constraint that you could only have one of any attribute on any element
then there would be no problem with layering.  But that is a fairly hard
bit of the XML model - undoing that would be quite chaotic!)


>If having ./foo and foo be different namespace names is totally
>unacceptable ie you will publicly unrecommend your own recommendation

Our own recommendation. A lot of people worked on it and a lot of people
missed the creeping inconsistency.
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.  i can't see any other way out of this
mess.

It is IMHO better to clean up now and get it right than stand on our pride.
A lot more will be built on this than has been.

>rather than have the status quo maintained, which would throw
>everything into chaos, then as a fallback position I'd urge
>consideration of Jonathan Marsh's suggestion that namespace names
>are always taken relative to some fixed base URI (any will do,
>to be specified in an addendum to the namespace spec).


Problems with that:

1. It is against the URI spec.

2. It actually messes up people who wnt to use them really as relative URIs.

>This would not affect any documents using absolute namespace
>uri and in practice wouldn't affect any documents using
>relative ones either (apart from test examples I don't believe
>any real documents will be using foo and ./foo as different
>namespaces)

I don't think we have  seen any real live examples of
relative URI use for namespaces at all -- it is just software.

> but most importantly it avoids the really horribly
>unacceptable behaviour of documents having element names depending on
>the context (and being undefined in general) that is the result
>of taking namespace names relative to the document base URI
>(if it has one).

My proposal was that we recommend against the practice of using relative at
all
for namespaces on account of this confusion.

>Personally I prefer the status quo to this suggestion, but
>most of your arguments against that appear to resolve around
>objecting to ./foo being different to foo, and if the above
>mechanism can resolve that and not have any bad effects in practice
>could we all agree to live with that?


if - but it has bad effects in practice.

>David
>

Received on Friday, 2 June 2000 09:46:51 UTC