- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 18 Feb 2009 15:12:22 +0200
- To: Mark Birbeck <mark.birbeck@webbackplane.com>
- 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>
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 hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Wednesday, 18 February 2009 13:13:04 UTC