On Nov 30, 2009, at 15:38 , Lachlan Hunt wrote:
>> The lack of namespace resolution in selectors is extremely annoying
>> because it means that one has to switch between selectors (if only
>> for classes support) and the XPath APIs for namespace support
>> whenever one tries to do, you know, one of those real-world things
>> where you have to aggregate data from multiple sources that might not
>> be talking to one another.
>
> Please clearly explain what "one of those real-world things" are, where selectors without namespaces is inadequate. In fact, if you could show some real world examples of where sites are switching from selectors api to xpath for the namespace support, or using some other work around, that would go a long way towards understanding what the use cases are, and what problems really need to be solved, as well as help in determining whether or not the problems are significant enough to be worth addressing.
Well, the fact of the matter is that no matter how much energy one might spend pointing out the issues, you'll still come back and say that we don't have a case where "the problems are significant enough to be worth addressing". So where do we go from here?
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.
Some people did try to specify over-engineered and useless mechanisms based on getting prefixes from a Node. I've been tracking this since this group exists, and I have yet to see a convincing argument that it can't be done simply. Show me a case in which there is a genuine issue, and we might have an informed discussion.
--
Robin Berjon - http://berjon.com/