Re: [selectors-api] querySelector with namespace

On Nov 26, 2009, at 15:13, Jonathan Watt wrote:

> Nevertheless, that doesn't mean that Web
> content shouldn't be able to process XML that uses xml:id using script and
> present the processed information to the user using content and semantics that
> *does* "belong on the Web".

The argument could be made that scripts should be able to process XML that depends on the PSVI or any other complication that has been specced on top of XML, but I don't think the browser platform should support the PSVI, either.

>> xml:id doesn't enable functionality that the id attribute on HTML, MathML or SVG elements doesn't enable, but xml:id comes with all sorts of complications. In addition to this complication, it has the complication that in an xml:id-enabled world, an element doesn't have a single attribute that has IDness. Instead, it has to have two (the natural choice flowing from XML specs) or the IDness of attributes has to depend on the presence of other attributes (the choice taken by SVG 1.2 Tiny).
> 
> I've been active in the Mozilla bug report filed for xml:id, so I'm aware of the
> issues. To my knowledge these have all been resolved satisfactorily, and the
> only reason the patch that was landed in Mozilla (net increase of 80 lines of
> code) didn't make it through to a release in 2007 was because of a performance
> regression, causing it to be removed. That issue is now also thought to be
> solved I believe.

I didn't mean just the perf issue in the context of Gecko. I meant complications in the context of just about any piece of software that deals with XML. 

Back when I added xml:id support to Validator.nu at least two people working on Web advised me not to. (They may make themselves known if they want to.) I thought adding support was super-simple. However, xml:id complicated the app in just about every place that's IDness sensitive, because I now had to take into account multiple ID attributes on a node. (I've since started phasing out xml:id support from Validator.nu, but I haven't completely removed all xml:id-motivated code, yet.)

Anyway, so far, it seems to me that xml:id seems simple at first but leads to complication. Yet, it doesn't address any use cases that hard-wiring IDness to id doesn't address. 

> Having said all that, I'm not very keen on adding native support for xml:id. I'd
> rather just make 'id' in the null namespace "special" if at all possible. KISS,
> right?

Indeed. Works for everything I've seen so far, except Chemical Markup Language. 

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

Received on Thursday, 26 November 2009 14:49:44 UTC