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

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






If having ./foo and foo be different namespace names is totally
unacceptable ie you will publicly unrecommend your own recommendation
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).

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

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?

David

Received on Thursday, 1 June 2000 18:47:54 UTC