Last time, I wrote: >>In the latest XalanJ and XalanC, that expression gets no nodes, but referring to //[name()='a']/c/@d and meaning that I put the expression in a stylesheet, so that there were namespace declarations available.
>It gets nodes. That is the problem. You show a method of calling the pure XPath with no context of namespace bindings, and you set up the source tree from <a xmlns='b'><c d='f'/></a> so the only effect on the default namespace is to set it once at the top of that tree. If you're getting nodes, then that is a problem. The crux of the matter as I see it is the /c step. In the XPath expression, that's asking for a node named 'c' in no namespace. Maybe the headline for the bug could be "StringReader constructs tree with element in wrong namespace" and further debugging should be directed at that c node. .................David Marston
