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

Re: RDFa and Web Directions North 2009

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 18 Feb 2009 15:12:22 +0200
Cc: Julian Reschke <julian.reschke@gmx.de>, Ben Adida <ben@adida.net>, Karl Dubost <karl@la-grange.net>, 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>
Message-Id: <C26B7520-0D34-428F-B76E-918B7A0277BD@iki.fi>
To: Mark Birbeck <mark.birbeck@webbackplane.com>
On Feb 18, 2009, at 14:04, Mark Birbeck wrote:

> The second aspect of this debate is that, provided the HTML5 spec
> doesn't do anything that breaks backwards-compatibility with current
> browsers, then we can *already* do clever stuff with RDFa in HTML5. We
> don't need anything extra in the specification -- thanks for asking.
> Now, if you break backwards-compatibility -- for example, by stripping
> out attributes that begin with a certain six character sequence --
> then that's obviously going to be a problem.

The concept of mapping HTML5 to XML Infoset and exposing the Infoset  
through XML APIs in order to enable the reuse of existing XML tooling  
in non-browser applications is backwards compatible with the way HTML  
4.01 could be mapped to XHTML 1.0. No feature currently drafted in  
HTML5 breaks this powerful way of reusing the XML toolchain. However,  
adding RDFa with xmlns:foo syntax would break this unless HTML5  
parsers took on more complication than currently defined.

(Wasn't the RDFa community supposed to care more about non-browser  
consumers than browsers?)

> What you are essentially saying is that "your argument that there is
> no work involved in allowing RDFa to be parsed in JavaScript, in
> HTML5, is bogus because there _is_ work involved...to undo the way
> that we have broken backwards-compatibility".

There's work involved in exposing things in Namespaces-wise correct  
APIs. (Including DOM Level 2; DOM Level 1 is not Namespace/Infoset- 
wise correct.) This applies both to browser-internal APIs if you ever  
want performant native support and to non-browser scenarios today.

>> Note that the Validator.nu HTML Parser currently exposes a XOM  
>> tree, so a
>> parser exposing XOM is not a theoretical construct. None of the  
>> currently
>> drafted HTML5 features need the change that exposing xmlns:foo- 
>> based RDFa
>> would require for consistency with the exposure of xmlns:foo in XML.
> You mean the un-change. We're not talking about exposing attributes,
> we're talking about not suppressing them.

An attribute called xmlns:foo cannot exist as an attribute in an API  
that treats attributes spelled xmlns:foo as artifacts of the  
Namespaces layer rather than attributes exposed to the application  
layer (e.g. XOM).

Also note that SAX2 in its most correct configuration doesn't expose  
xmlns:foo as an attribute.

> I think this is incorrect. There is no mapping needed, because an
> attribute called "xmlns:dc" is just that; there is nothing special
> about it in an HTML document.

But there is something special about it in an *XHTML* document, which  
means the speciality is *different* in HTML vs. XHTML. Binding higher- 
layer behavior to something that is *different* in HTML vs. XHTML is  
always trouble even if the trouble seems tiny at first.

Henri Sivonen
Received on Wednesday, 18 February 2009 13:13:04 UTC

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