XOM API for Processing XML with Java

[Michael Kay <mike AT saxonica.com>]

I suspect Jaxen was written with some awareness of the way the spec 
moved after XPath 1.0, but without going all the way to 2.0. Further 
complicating matters is that the W3C specs have nothing to say about 
what APIs can do; and the 1.0 spec has only the haziest description of 
the static context.

XPath 1.0 explains how a QName in a NodeTest is expanded (no prefix 
means no namespace). But it doesn't say how a QName in a function name 
is expanded. I think one can assume that the authors intended system 
functions such as "not" to be in no namespace, and it pretty well 
follows that function names can't be expanded using the default 
namespace because that would make system functions inaccessible.

Generally XPath 1.0 is a pretty lightweight spec which is probably why 
it has been so successful. It doesn't waste time discussing edge cases, 
which can make it very frustrating for implementors.

Michael Kay
Saxonica

On 05/05/2012 01:50, Elliotte Rusty Harold wrote:
> I've fixed the one you reported as a bug in my local client. I think
> your workaround should also fail:
>
>      public void testNotWithNamespaceWorkaround() throws
> ParsingException, IOException {
>
>          Document doc = new Builder().build(new StringReader("<root
> xmlns='http://www.example.org'/>"));
>          XPathContext context =
> XPathContext.makeNamespaceContext(doc.getRootElement());
>          context.addNamespace("a", doc.getRootElement().getNamespaceURI());
>          context.addNamespace("f", "");
>          Nodes query = doc.query("//*[f:not(self::a:test)]", context);
>          assertEquals(1, query.size());
>
>      }
>
> I.e. "//*[f:not(self::a:test)]" is not a correct XPath 1.0 expression,
> at least not when f is bound to the empty string.
>
> Michael, what do you think?