- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 18 Feb 2009 13:28:53 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Ben Adida <ben@adida.net>, Karl Dubost <karl@la-grange.net>, Mark Birbeck <mark.birbeck@webbackplane.com>, 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 17, 2009, at 19:24, Julian Reschke wrote: > Henri Sivonen wrote: >> ... >> Although this looks like a non-problem in browsers because the >> Namespace-unaware DOM Level 1 view is available, it is a technical >> problem with APIs that only provide a Namespace-aware >> representation. For example, XOM doesn't allow attributes called >> xmlns:foo in the data model. Non-browser consumers are important, >> and it should be perfectly reasonable to use XOM in such a consumer. >> ... > > 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. 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. >> There's also a technical issue for browsers: For resolving a prefix >> in a namespace mapping context on the XML side in a browser, it >> would make sense to intern the prefix being queried and then do >> pointer compares against interned local names of attributes in the "http://www.w3.org/2000/xmlns/ >> " namespace as traversing up the tree. If you ever wanted browsers >> to implement any RDFa features natively, being sensitive to >> xmlns:foo attributes set with setAttribute() would preclude a >> pointer compare-based lookup and would require actually inspecting >> string data unless the internal data structures of browsers were >> changed. (But see point #13 in my previous email on the topic of >> changing the data structures.) > > That doesn't seem to be true. An implementation of setAttribute (L1) > would just need to know that an attribute named "xmlns:*" is > something special, and internally map it. Well, internally mapping it specially would be a non-zero change/cost on browsers making the line of argument that there's no cost or action required on behalf of browser vendors bogus. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Wednesday, 18 February 2009 11:29:35 UTC