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

Re: RDFa and Web Directions North 2009

From: Sam Ruby <rubys@intertwingly.net>
Date: Fri, 13 Feb 2009 14:02:38 -0500
Message-ID: <4995C3CE.7070802@intertwingly.net>
To: Mark Birbeck <mark.birbeck@webbackplane.com>
CC: 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 <hsivonen@iki.fi>

+cc hsivonen

Mark Birbeck wrote:
> Hi Sam,
> There are many interesting things to reply to in this discussion, but
> I'll keep this particular post to one comment you make:
>> There are legitimate questions in these areas as it has been
>> observed that RDFa was designed based on the presumption of XHTML parsing
>> rules, and HTML parsing rules differ in visible ways from XHTML.  Ways that
>> affect the specific names of attributes chose in RDFa.
> This should read "it has *incorrectly* been observed that RDFa was
> designed based on the presumption of XHTML parsing rules".
> :)

Ah, at last, a technical discussion!

Sounds great in theory.  Unfortunately, Henri has provided a test case 
that disproves this in practice:


> I can assure you that the parsing rules were very explicitly written
> in such a way that the only thing they require to do their work is a
> hierarchy of nodes, and the ability to obtain the value of an
> attribute. Since both HTML and XHTML DOMs provide that then the
> parsing algorithm will work in both. (In fact, XML DOMs in general
> provide this, so the parsing algorithm also works with SVG.)

Agreed if the DOM nodes produced are, in fact, the same.

> The desire to make the algorithm work in this very generic way runs
> deep in the whole design of RDFa. In fact, we even changed some of the
> parsing rules in response to testing we had done with HTML mode in
> different browsers.
> For example, early drafts of RDFa allowed for <meta> to appear
> anywhere in a document, the thinking being that <meta> was nothing
> more than a <span> that just happened to have the semantics that it
> was about semantics. :)
> However, it transpired that Firefox 'relocates' any <meta> tags that
> it might find in the <body> element, to the <head> element. It does
> this on initial load, which means that if you have a JavaScript
> parser, you have no way of knowing whether a <meta> element in the
> <head> was originally at that position, or came from the <body>.
> That's a serious problem if the <meta> element contains some
> context-dependent information, such as an attribute that contains a
> CURIE, or the parent element sets a new subject) this information will
> either be incorrect or impossible to work out.
> But our response was not to push ahead with some abstract idea of
> perfection that couldn't be used in today's browsers, and instead we
> took the pragmatic step of simply removing this facility -- <meta> can
> no longer appear anywhere in a document.
> The result is that there are already a number of parsers available
> that run within current browsers, even when the host browser is in
> HTML mode.
> Regards,
> Mark

- Sam Ruby
Received on Friday, 13 February 2009 19:03:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:15:03 UTC