This kind usage of xmlns in an xml doc is a hack done by SIMPLE WG breaking XML standard, because any ns has to use a prefix for each corresponding name. If you search on google, you will fine some discussions on the web (iirc, Inaki was there as well) - libxml2 devs said they don't want to break the xml standard to handle this case, probably they didn't change the mind meanwhile.

Anyhow, set a prefix for the namespace via xml_ns parameter and then use it in xpath

modparam("xmlops", "xml_ns", "di=urn:ietf:params:xml:ns:dialog-info")

$xml(u=>xpath:/di:dialog-info/di:dialog[1]/di:state/text())

Hope i remembered correctly, anyhow it is somewhere in this direction. If not, search on mailing list archive, the situation popped up few times around.

Cheers, Daniel

On 03/05/14 09:49, Alex Balashov wrote:

It's definitely namespace-related, because when I manually hack out the namespace, it works fine!

$var(x) = $rb; $var(x) = $(var(x){re.subst,/xmlns=".+"//});

$xml(u=>doc) = $var(x);

xlog("L_INFO", "State: $xml(u=>xpath:/dialog-info/dialog[1]/state/text())\n");

But I can't for the life of me figure out how to construct an XPath expression that properly captures the urn:ietf:params:xml:ns:dialog-info namespace.

On 03/05/14 10:33, Alex Balashov wrote:

On 05/03/2014 04:31 AM, Daniel-Constantin Mierla wrote:

...

This kind usage of xmlns in an xml doc is a hack done by SIMPLE WG breaking XML standard, because any ns has to use a prefix for each corresponding name. If you search on google, you will fine some discussions on the web (iirc, Inaki was there as well) - libxml2 devs said they don't want to break the xml standard to handle this case, probably they didn't change the mind meanwhile.

Anyhow, set a prefix for the namespace via xml_ns parameter and then use it in xpath

modparam("xmlops", "xml_ns", "di=urn:ietf:params:xml:ns:dialog-info")

$xml(u=>xpath:/di:dialog-info/di:dialog[1]/di:state/text())

Hope i remembered correctly, anyhow it is somewhere in this direction. If not, search on mailing list archive, the situation popped up few times around.

Thanks Daniel. I was heading in this direction, too, before I got lazy and just hacked out the xmlns attribute with {re.subst}. :-)

Probably would be good to add a module parameter to do this change internally, like replacing 'xmlns' with 'xmlnx' - iirc, there is a copy if xml doc in a local buffer and by sticking to same size, there is no overall size change, so just one char replacement.

This could come handy when needing just to read. If one needs to update the xml doc, then the above could break things when generating the new xml.

Cheers, Daniel