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

Re: Defaule base URI for files

From: David Carlisle <davidc@nag.co.uk>
Date: Fri, 19 May 2000 10:45:45 +0100 (BST)
Message-Id: <200005190945.KAA20526@nag.co.uk>
To: timbl@w3.org
CC: xml-uri@w3.org
> That (full DNS name) is best because it protects against the URI being
> interpreteded accidentally on another system. However, in practice
> many systems don't bother to or want to know thir own names
> and so just use
> file:///users/davidc/file.xml
> When this is being done by an XML processor on a given machine
> then so long as it is done consistently it won't matter which is done.

But that is exactly the point.

It "won't matter" what the base URI is for the purposes of constructing
relative links, because they are all functionally equivalent.

But for namespace use you have just confirmed that with the absolute
approach my example has _no_ specified namespace. Different systems are
allowed to infer different base URI and so produce different absolute
URI for the namsepace. Even under the absolute approach absolute
namespace uri are compared as strings not by functional equivalence.

So, I can't say what namesapce the elements in the file are in, I can't
query the document or style it by namespace aware tools unless I
use the rather unreliable process of ensuring that the stylesheet is
on the same machine as the document and then use a suitable relative URI
to declare the namspace in the stylesheet, then just hope that the
XSL system infers the same absolute URI from the relative URI in the
document and the relative URI in the stylesheet. But you have confirmed that
there is nothing in the uri spec that says I can definitely rely on this

"absolute" is just "forbid relative URI" in disguise. That would be OK
(there is no real need to use relative URI for namespaces) except
for the fact that you appear to be _encouraging_ the use of a relative
URI to point to a schema. How can that possibly work with the absolute

Received on Friday, 19 May 2000 05:46:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:58 UTC