Re: RDFa and Web Directions North 2009

+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:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-January/018242.html

> 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