Hey, Stefan Behnel wrote: [Torsten Rehn]
I'm making that much of a problem out of it because my app processes XML documents that use namespaces quite extensively. And these namespaces may be different for every XML doc that comes along, so I would have to scan the file for xmlns attributes first (and then call the .xpath() method with the second argument as described on the page you posted),
Unfortunately any lxml implementation of this behavior would have to do the same internally, so this is not an easy one to implement.
So you're really ignoring the namespace and just looking at the prefix? That's definitely an unusual use case.
Agreed, that is indeed odd. Makes me want to find out more. :) You have documents that use namespaces extensively, but they vary widely in the kinds of namespace URIs they use for the same prefixes? How did you arrive in such a situation?
What's the use in accepting any namespace in an XPath expression as long as the prefix is the same? I mean, honestly, the prefix doesn't tell you anything, right?
To make sure Torsten understands, ignoring the prefixes and looking at namespace URIs *is* the proper behavior for XML software. The prefixes are nothing but a shortcut, a temporary name, to refer to the namespace URI. This leads to confusion, and is why the ElementTree API in fact includes the whole namespace URI in the element names instead: "{http://mynamespace}foo" ("Clarke notation") ElementTree is rather strict in ignoring the prefixes entirely, which can be a bit frustrating if you are interested in the presentation of the XML document in the end. lxml follows ElementTree but offers various ways to do things with prefix. Unfortunately in xpath the compromise is to use prefixes only to spell out the XPath expression, as using the full qualified names would not be XPath compatible. Occasionally we've had some discussions about offering an API to do XPath queries using Clarke notation. Regards, Martijn