W3C home > Mailing lists > Public > public-rdfa@w3.org > February 2009

Re: RDFa and Web Directions North 2009

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 18 Feb 2009 15:21:53 +0200
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>
Message-Id: <FFADCD68-9E51-40CE-87AD-4E448931D8A6@iki.fi>
To: Julian Reschke <julian.reschke@gmx.de>
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  

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

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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:42 UTC