- From: Dan Brickley <danbri@danbri.org>
- Date: Wed, 18 Feb 2009 13:13:06 +0100
- To: Mark Birbeck <mark.birbeck@webbackplane.com>
- Cc: Henri Sivonen <hsivonen@iki.fi>, 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>, 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 18/2/09 13:04, Mark Birbeck wrote: > Hi Henri, > >>> Could you elaborate what exactly the problem with XOM is? I didn't get it >>> from this paragraph. >> It doesn't represent XML attribute spelled "xmlns:foo" in the XML source >> code as attributes in the API. Thus, if you write a XOM-based consumer for >> RDFa-in-XML as currently defined, you can't just swap the parser to an HTML5 >> parser and have it work. >> >> You'd need to change the HTML5 parser to expose attributes spelled >> "xmlns:foo" in the same way XML namespace mapping context is exposed. Such a >> change would be a non-zero change with non-zero cost making the line of >> argument that RDFa using attributes spelled "xmlns:foo" involves zero >> cost/change to HTML5 implementors bogus. > > There are two aspects to this debate. Some people want RDFa to be > added to HTML5, and that browsers do something with it. I'd love to > see that too, but then I'd also like to solve world hunger, and teach > the world to sing. > > 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. I think you're missing a case here: Many of us are working in environments where (at least looking to the future) documents are expected to be (in some sense) valid. And for better or worse, HTML5 looks like it will be the (or at least "a") dominant browser-supported document format, which many people and organizations will want to use (eg. for the new APIs and fun extras). Those of us who hope to have such documents carry RDFa will be out of luck, if we're in organizations who have some commitment to validating their HTML. Sure, those orgs are in a minority, ... but they are a minority with a lot of interesting and important data. So, I think you miss an important constituency here. Those who: * don't need browsers to do anything with the RDFa other than tolerate it and expose it in low-level APIs * expect HTML5 to be widely used * expect to have RDFa embedded in HTML5 * expect those HTML5 + RDFa documents to validate cheers, Dan
Received on Wednesday, 18 February 2009 12:14:04 UTC