Re: RDFa and Web Directions North 2009

On Feb 18, 2009, at 13:49, Julian Reschke wrote:

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

Absent RDFa, it clearly isn't a bug in either. RDFa is what adds a  
problem.

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

No. On the contrary, the parser is explicitly allowed not to expose  
them. But obviously, that solution wouldn't work for RDFa as proposed.

| If the XML API doesn't support attributes in no namespace
| that are named "xmlns", attributes whose names start with
| "xmlns:", or attributes in the XMLNS namespace, then the
| tool may drop such attributes.
http://www.whatwg.org/specs/web-apps/current-work/#coercing-an-html-dom-into-an-infoset

>>> 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 :-)

Evidence suggests they don't do it already.
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-January/018242.html

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 18 February 2009 13:22:35 UTC