W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > August 2004

RE: On xml:base [was RE: XHTML 2.0 metainfo question (Correction!!!)]

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Wed, 4 Aug 2004 12:29:53 +0100
To: "'Dan Brickley'" <danbri@w3.org>, "'Jeremy Carroll'" <jjc@hplb.hpl.hp.com>
Cc: <public-rdf-in-xhtml-tf@w3.org>
Message-ID: <005b01c47a16$5cd2e210$6f01a8c0@W100>


> > This xml:base example is simply illegal - namespace 
> declarations must 
> > be
> > absolute - (a plenary decision). See errata of Namespaces 
> in XML 1.0 or 
> > Namespaces 1.1.
> > 
> > It generates an error and no triples.
> Thanks Jeremy. I'd forgotten that decision had been 
> formalised to that extent, was remembering it more as 'best 
> practice' convention. So it wasn't a trick question.

Well ... I was of the same opinion, Dan, although that doesn't alter the
core of what Jeremy is saying, which is that we shouldn't support it.

I think we're supposed to handle the 'error' at the level of our spec,
rather than there being some fundamental 'error' at some deeper level. This
means that we say in our spec something along the lines of 'relative URIs
are not in the scope of this spec', or 'predicates defined using relative
URIs are undefined and so generate unpredictable triples'.

Other than that I'm not sure what we can do, since I don't know where we'd
"generate an error" - does the DOM do it, the XHTML processor, the RDF/XHTML
processor, or what? They all *could* do it, but equally my understanding of
the Plenary decision is they are also allowed to just say 'undefined' for
relative URIs in namespaces.

So, since we can't be sure that anything 'underneath us' (the DOM, the XML
InfoSet or the XHTML 2 DOM) has halted processing, then we may actually
receive a predicate that has a relative namespace.

Anyway, as I said, none of this changes the thrust of Jeremy's point that
this is deprecated behaviour.


Received on Wednesday, 4 August 2004 07:30:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:18 UTC