W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: [selectors-api] querySelector with namespace

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Mon, 30 Nov 2009 16:46:10 +0100
Message-ID: <4B13E8C2.2030601@lachy.id.au>
To: Robin Berjon <robin@berjon.com>
Cc: public-webapps@w3.org
Robin Berjon wrote:
> There are quite a few services out there that return XML — it would
> be  disingenuous to pretend otherwise. The addition of x-site requests to
> the stack makes these even more available. XHR supports XML natively,
> including namespace. Selectors support namespaces natively.
> Implementations already support that — exposing it at the API level is
> hardly a massive cost. So apart from saying that all of these are wrong,
> or saying that XML, XHR, Selectors aren't part of the web stack I can
> hardly see where your argument is going.

No-one is disputing the fact that those tools exist and that they could 
be used for XML with namespaces.  But are those tools being used in ways 
that utilise namespaces in useful ways, such that having them exposed at 
the selector API level would be either useful or even necessary?

How about we take a look at some public website APIs using XML that 
could be suitable for use in cross site requests, and see which, if any, 
could possibly benefit from supporting prefixes in this API?

Twitter: http://apiwiki.twitter.com/Twitter-API-Documentation
Does not use namespaces at all, would not benefit from it being added to 
this API.

Flickr:  http://www.flickr.com/services/api/
Again, does not use namespaces at all.

Validator.nu: http://wiki.whatwg.org/wiki/Validator.nu_Web_Service_Interface

This does use namespaces in the XML version of it's API.  It nests 
fragments of the XHTML markup within the <message> and <extract> 
elements.  These tag names don't clash with any in XHTML, and so they 
can be selected without bothering about namespaces, or by using a 
selector like

   To select any of the XHTML itself, it's easy enough to use a selector 

"error>elaboration div" or "info>message code"

The source element does clash with the source element in HTML5, but it 
can be easily and unambiguously selected using "messages>source".

So, even if a script opted for the XML output, there is no clear 
dependency on using namespaced selectors here.

Besides, all of those APIs mentioned also offer JSON output, which is 
much more optimised for use in JavaScript environments where cross site 
requests will be most common.

So what other sorts of APIs do you have in mind which would greatly 
benefit from namespace support in selectors API?  It would help if you 
could find some other APIs and illustrate with some real world sites 
that use them, where namespace-supporting APIs are utilised for good 
reasons on the client side.

Lachlan Hunt - Opera Software
Received on Monday, 30 November 2009 15:46:50 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:21 UTC