Re: Use cases

Tim Berners-Less said

> I'd like to look in more detail at the question as to whether any actual
> damage would occur were the NS spec to changed to require
> absolutizing for comparison. I contend that, because in fact that is
> consistent with URI behavior, it will not cause problems with existing
> documents in practice.

Consider an html file available from
http://www.w3.org/example/a.html

that contains the relative URI construct <a href="/1999/XSL/Transform">

then the effect of using the local link is that the link works as
intended if the whole site (or just the relevant subset of it)
is copied to another site, or just accessed as WWW.w3.org
this is why relative URI have proved so useful, they allow related files
to be moved together, with links staying intact.

Now consider the case for namespaces with the "absolute" interpretation

consider an XSL file available from
http://www.w3.org/example/a.xsl

that starts

<xsl:stylesheet xmlns:xsl="/1999/XSL/Transform"
                version='1.0'>

This would be a valid XSL file, as the effective namespace of
the document element would be http://www.w3.org/1999/XSL/Transform

However the result of using relative namespace here would be that the
document can not be moved or accessed via any other URI, if you access
it as http://WWW.w3.org/example/a.xsl then under the absolute
interpretation the file is suddenly no longer XSL. This is perhaps logically
consistent with the `default URI behaviour' as used in links but I don't
see it as desirable in any way.

With the "literal string" interpretation, a.xsl isn't XSL at all, as the
namespace is never XSL.

This example is typical: using relative namespace URI under the absolute
interpretation _always_ means that the document may not be moved or
viewed from a different server. Thus effectively the complete reverse of
the situation for links.

This is why I argued before that the use of relative URI for namespaces
under the absolute approach is so unlikely.

David

Received on Thursday, 18 May 2000 14:30:16 UTC