W3C home > Mailing lists > Public > xml-uri@w3.org > May 2000

Re: Use cases

From: Tim Berners-Lee <timbl@w3.org>
Date: Sat, 20 May 2000 18:57:35 -0400
Message-ID: <00fb01bfc2ae$d42732e0$e9a55c8b@ridge.w3.org>
To: "David Carlisle" <davidc@nag.co.uk>, <xml-uri@w3.org>
Abstract:  Your scenario with absolutization is just a user making a bad
document under a consistent spec.
But my scenario without absolutization  demonstrates that such specs would
be inconsistent.

Tim

-----Original Message-----
From: David Carlisle <davidc@nag.co.uk>
To: xml-uri@w3.org <xml-uri@w3.org>
Date: Thursday, May 18, 2000 2:30 PM
Subject: 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


That is true. However, the person who uses a relative link only does so if
they
want a specifically local reference designed to move if the document is
copied.
This is a standard - no user is going to be likely to use that (and anyway
only those publishing on W3C could, and they would get it in the neck from
our Hugo!)

Users are generally aware of the properties of relative names. They don't
use 'em if they don't mean 'em.

I know you can construct this case - but is it likely to happen in practice?

And thi is a case of a document which the user has written to do the wrong
this, but
quite a consitent system.  We haven't got a bug in which a validator says
someting
is incorrect when in fact when processed it is fine. We dont ahve an
inconsistent
system as we have with the literal comarison. There is a very big diference.

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


So don't do it.  This same arguments apply to images and links and I think
people know. It is not an inconsistency in the specs.

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


No, I gave a long example of a virtual schema in a database which
always moved wth the data. Please see
http://lists.w3.org/Archives/Public/xml-uri/2000May/0281.html

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

Unlikely - but someimes a good idea.  When a group decides to outlaw
certain use of the technology, removing aa corner from a nicely rectangular
feature set, it doesn't sound good. Doesn't sound like a powerful universal
system
is getting designed.

>David


Tim
Received on Saturday, 20 May 2000 18:55:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:42 UTC