- From: Tim Berners-Lee <timbl@w3.org>
- Date: Sat, 20 May 2000 18:57:35 -0400
- 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