Re: RDFa and Web Directions North 2009

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/