I will try to use the PrefixResolver class. Thanks.
Yes, there is. Look at the SimpleXPathAPI sample, and you'll see it uses a class called XalanDocumentPrefixResolver. You can use that class, if the namespaces you're interested are declared in the incoming document, and you can predict the prefixes. Otherwise, you can decide on a set of namespace bindings that you expect, and create your own derivative of Xalan-C's PrefixResolver class. > > But actually, even the 'soap' prefix is used here only because the > document defines it as the prefix of > "://schemas.xmlsoap.org/soap/envelope/". In real life, I would not be > able to tell if the soap server defines it as "soap" or maybe "s" or > "soap12" etc. The only sure thing is the namespace uri and the local > node name. That's why prefixes are irrelevant. The namespace URI is the only thing that matters, once Xalan-C has compiled the XPath expression. But it needs a PrefixResolver instance to do the mapping. > > So now I have 3 options: > 1) Use the API with expression containing '*' and local-name() and > namespace-uri() functions (not efficient???) > 2) Use the API with expression containing myPrefix:myNodeName, but > "teach" the API first what is the namespace uri of 'myPrefix' (not sure > it's possible) > 3) Use a stylesheet instead of the Xpath API. I will create the > stylesheet dynamically in my code with all the known namespaces uri and > prefixes. And then extract the text using xsl. (not sure that the result > of xsl can be a simple text and not xml, and also not sure it is more > efficient then the first method). Use a custom implementation of PrefixResolver that knows all of the prefix/namespace URI bindings in your XPath expressions, and ignore the prefixes in the incoming document(s). Dave
