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

Re: Updated RDFa-in-text/html tests

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Fri, 5 Jun 2009 14:58:41 +0100
Message-ID: <ed77aa9f0906050658j188a40b8hf93215ac6067ee83@mail.gmail.com>
To: Shane McCarron <shane@aptest.com>
Cc: Jeni Tennison <jeni@jenitennison.com>, Philip Taylor <pjt47@cam.ac.uk>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>
Hi Shane,

> FWIW - RDFa requires the use of XML Namespaces 1.0, not 1.1.  As a result, I
> think that both of these tests are wrong.  As Philip points out, in XML
> Namespaces 1.0 an empty xmlns value is illegal, so such a value MUST be
> ignored by an RDFa processor.  My implementation does not correctly do that,
> but I am updating it right now.

I'm not totally convinced we can get around this so easily.

First, the RDFa spec doesn't refer to XML namespace processing as
such, but simply to the XML namespace attribute technique:

  "In RDFa these mappings are expressed using the XML namespace

And since the processing rules themselves keep track of 'prefix
mappings', the language, DOM, or whatever is being processed doesn't
actually need to support XML namespaces for mappings to work.

So, whilst at the level of a conformant XML+XMLNS document, having
@xmlns:xyz="" might be invalid (and so might mean that an RDFa parser
never even sees the document), we haven't actually unambiguously ruled
out empty prefix mappings in our processing model.

To put it a different way, because we obtain the attribute name and
its value as if it was a normal attribute, and not by asking the XML
processor for a list of namespaces, we're not actually restricted by
normal XMLNS rules.

If we want to be restricted in this way, that's ok, but then we
probably need to add something via an errata.

I don't have a problem with doing that, but if we do go down that
route I'd further suggest that we define the change in such a way that
it is not XMLNS-specific.

For example, we might say that any empty prefix mappings are ignored,
and therefore won't be used in CURIEs. This would then ensure that
empty mappings that are created with the newer prefix mapping
solutions under discussion -- such as @prefix and @token -- would also
be ignored, creating consistent results.

(There may be arguments that this is too restrictive, which is fair
enough; my point though, is that however we frame this, it would be
good if it could be done in terms of the prefix mappings themselves,
rather than explicitly relating to @xmlns.)

Anyway, as the spec stands at the moment, I think it is legitimate for
processors to parse a prefix mapping that's empty, and then to use
that in a CURIE.



Mark Birbeck, webBackplane



webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)
Received on Friday, 5 June 2009 13:59:22 UTC

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