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

Re: Fixed base

From: Daniel Veillard <Daniel.Veillard@w3.org>
Date: Tue, 20 Jun 2000 13:07:11 +0200
To: James Clark <jjc@jclark.com>
Cc: xml-uri@w3.org
Message-ID: <20000620130711.L24324@w3.org>
On Tue, Jun 20, 2000 at 12:50:31PM +0700, James Clark wrote:
> I've been quite surprised to find that this debate has actually
> changed my views.  I now believe the right solution is to absolutize
> namespace names relative to a fixed base URI of something like
> "contextdependent:/" and then perform a character-for-character
> comparison (I'll call this solution "fixed base" for short).  Several
> people have already voiced their support for similar proposals:
>    http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0347.html
>    http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0601.html
>    http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0647.html
> The effect of "fixed base" is very similar to the "literal" solution;
> except for URIs containing "." and ".." it will be the same. 
> [...]
> it avoids the key problem of the "literal" approach: with "fixed base"
> there's never a case where two URIs are namespace equal but refer to
> different resources; thus an application such as RDF that needs to
> dereference namespace URIs can be consistently layered on top of
> "fixed base". 

   Hum, assuming upper layer processing is based in the generated
Infoset, then those won't be dereferencable in practice. One can still
use them for comparaison or making assertions about them though.

> It also avoids the key problem with the "deprecate"
> solution, which is to specify what happens when documents use relative
> namespace URIs despite their being deprecated.


> [...]
> It also opens the way to a further simplification. An element with no
> namespace name can be treated as having a namespace name of
> "contextdependent:/".  This makes the behaviour of xmlns="" not be an
> ugly special exception, but just a consequence on the normal rules on
> resolving relative URIs.  This gives a very clean data model: every
> element, without exception, has an expanded name consisting of an
> absolute URI (with an optional fragment identifier) and a local name.

  I like the unification, I like the fact that existing documents using 
relative namespace won't break (at parsing). This looks solid.

  But it forbids to use a namespace name be an URI relative to the document
one. I don't know if designing a packaging model where "contextdependent:/foo"
could be dereferenced would be a solution for the technical need of
associating the schemas informations with the document location. This could
also be handled using another mechanism to associate an URI Reference
with a namespace (in Schemas?).

  I also wonder what is the impact on the other specifications, would XPath
need to be amended ?


Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes  | Today's Bookmarks :
Tel : +33 476 615 257  | 655, avenue de l'Europe | Linux XML libxml WWW
Fax : +33 476 615 207  | 38330 Montbonnot FRANCE | Gnome rpm2html rpmfind
 http://www.w3.org/People/all#veillard%40w3.org  | RPM badminton Kaffe
Received on Tuesday, 20 June 2000 07:07:31 UTC

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