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

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

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


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

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

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

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



David

Received on Friday, 2 June 2000 13:20:19 UTC