W3C home > Mailing lists > Public > public-rdfa@w3.org > February 2009

Re: RDFa and Web Directions North 2009

From: Ben Adida <ben@adida.net>
Date: Mon, 16 Feb 2009 23:28:04 -0800
Message-ID: <499A6704.8070405@adida.net>
To: Henri Sivonen <hsivonen@iki.fi>
CC: Karl Dubost <karl@la-grange.net>, Mark Birbeck <mark.birbeck@webbackplane.com>, Sam Ruby <rubys@intertwingly.net>, Kingsley Idehen <kidehen@openlinksw.com>, Dan Brickley <danbri@danbri.org>, Michael Bolger <michael@michaelbolger.net>, public-rdfa@w3.org, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, Tim Berners-Lee <timbl@w3.org>, Dan Connolly <connolly@w3.org>, Ian Hickson <ian@hixie.ch>
Henri Sivonen wrote:
>> JavaScript
>>     * RDFa Bookmarklets
>>       Author: Ben Adida
>>       http://www.w3.org/2006/07/SWD/RDFa/impl/js/
> This one reads xmlns:foo using a namespace-unaware DOM Level 1 view.
> See points 4 though 7 in my earlier email.

You provided an example that supposedly breaks RDFa parsing. I showed
you a library that works without any code fork on HTML/XHTML. Now,
you've come up with new conditions.

If I show you that these conditions are, in fact, satisfied, will there
be more conditions? Is there an official list of conditions that you're
reading from?

So let's examine:

> 4) The qname is an artifact of [....]

We're not using QNames. We've defined the CURIE datatype with explicit
parsing rules, and we've specifically defined them as *not* mapping to
(namespace,local), but instead to a full URL.

So, just to be extra clear. We don't use QNames, we don't use browser's
handling of QNames, and whatever brokenness might exist with QNames
doesn't apply to CURIEs or RDFa.

We only use the xmlns declarations of mapping prefixes, never QName

> 5) Given the points above, you should also do dispatch on the
> [namespace,local] pair on the HTML side.

Only if RDFa fields were defined as QNames. They're not.

> 6) All features going into HTML5 should be robust and sane under
> scripting even if the people proposing the feature where interested
> in read-only use case is outside browsers. This includes keeping
> script-generated DOMs serializable.
> 7) If, in order to satisfy point #2 above, your feature requires
> using getAttribute (without NS) on getting but setAttributeNS (with
> NS) on setting (to keep the XML DOM serializable!), your feature
> isn't satisfying point #6.

Mark is right on this: RDFa parsing remains easy and consistent. The key
is to *never* use setAttributeNS or getAttributeNS. Since RDFa doesn't
use QNames, that's not surprising.

We do use xmlns prefix bindings, but we don't need to rely on the
browser to parse those bindings, we can do that ourselves easily,
exactly as if we had used @prefix all along.

So, to implementors, we simply say: use setAttribute and getAttribute,
*never* setAttributeNS or getAttributeNS.

I've expanded our evolving example to show that, no matter the mime type:

- you can dynamically add RDFa to the DOM using setAttribute.

- you can serialize the resulting DOM appropriately using innerHTML.

- you can parse the new RDFa as if it had been there from the start
using the exact same algorithm that uses getAttribute.



Same bytes, different mime type.

Try the following using Firefox or Safari:

- extract RDFa from page
- reload the original page (only because the bookmarklet overwrote your
- show HTML chunk below
- add RDFa to updated page
- show HTML chunk below
- extract RDFa from page

The only difference you'll see in the serializations is the same
difference you see without RDFa: an extra xmlns="..." in the SPAN when
in XHTML mode. It's important to note that, in RDFa, we specifically
*ignore* the xmlns="..." attribute, we only look at specific prefix
bindings like xmlns:dc="..."

I think it's safe to say that we have a robust and sane way to
consistently parse RDFa in both HTML and XHTML DOMs, with robustness
across DOM manipulation and serialization, even when using xmlns:*. The
key is to remember that we don't use QNames.

So, I maintain my claim that the opposition to xmlns:* is mainly one of
personal taste, not a technical problem of any sort. I'm certainly
receptive to this issue of taste, which is why I'm happy with our
@prefix explorations.

But it's important to be clear about why we're doing this: it isn't a
technical limitation or even a question of developer consistency.

Received on Tuesday, 17 February 2009 07:28:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:42 UTC