Re: RDFa and Web Directions North 2009

Henri Sivonen wrote:
> 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.

It appears to me that this could be considered to be either a bug in the 
HTML5 parser, or in XOM.

> 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 

Yes, I know that.

> 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.

So is there a precise requirement in HTML5 that mandates how a parser 
must expose xmlns:foo when producing SAX events, for instance?

>> 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.

I would assume that a sane implementation that supports both DOM level 1 
and DOM level 2 already does that. But I've been wrong on the smarts of 
DOM implementations before :-)

BR, Julian

Received on Wednesday, 18 February 2009 11:50:13 UTC