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

Re: RDFa and Web Directions North 2009

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Fri, 13 Feb 2009 18:39:59 +0000
Message-ID: <ed77aa9f0902131039q1a515f3cx54f1da4b81894d54@mail.gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
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>

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".


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.)

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.



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, 13 February 2009 18:40:38 UTC

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