Ah, I see now.

The code you point to is relying on NodeTest.toString() returning a valid XPath representation of the NodeTest. The toString() methods on classes like NodeTest are not designed or guaranteed to return a representation of the NodeTest that can be pumped straight back into the XPath parser. The Javadoc for NodeTest.toString() states that the output is intended "for diagnostics"; the javadoc for Object.toString() states

        In general, the
     * <code>toString</code> method returns a string that
     * "textually represents" this object. The result should
     * be a concise but informative representation that is easy for a
     * person to read.

So I think it's clear that the output of toString() is intended primarily for the human user, and I therefore don't think it's unreasonable for Saxon to return a representation of the NodeTest that can only be parsed using XPath 3.0, given that this allows us to make the namespace URI explicit.

Making toString() on expressions and related classes guarantee to return a parseable representation of the expression might be useful, but it's not currently something we attempt.

Michael Kay

On 09/08/2012 17:05, Ronald van Kuijk wrote:



This ‘generated’ xpath is what we get back from Saxon in the originally parsed expression. This splitting happens recursively based on the type of the expression in https://github.com/betterFORM/betterFORM/blob/development/core/src/main/java/de/betterform/xml/xpath/impl/saxon/SaxonXPathExpressionSerializer.java (still the version there)


The same xpath was returned in Saxon in which it worked. In Saxon it was


../child::element(amount, xs:anyType)


So if




Is the xpath3 format that is returned by Saxon while I’m still in xpath2 mode (that is the default right?) should it not also accept this? E.g. by checking if a backwards compatibility flag is set (or a ‘forward compatibility flag’?) or still return the xpath in the ‘old’ pre xpath3 format? Now I know this, it also explains clearly why our referencefindertests fail.


To check if I missed other issues in the SaxonExpressionSerializer (new xpath constructs that are now returned by Saxon) I changed




which we use to create a string reprentation of an element in an axis expression that, in this case returns element(‘’:amount) to



                        String nt = nodeTest.toString();

                        int startName = nt.indexOf(":")+1;

                        int endName = nt.length() -1 ;

                        result.append(nt.substring(startName, endName));

                        result.append(", ");




to get the ‘original’ saxon pre 9.3 version of element(amount, xs:AnyType).  After that I needed to implement ‘serializing’ the LetExpression which was returned by Saxon when creating an Expression for


count(observation[/data != '']/code) > 0


But up to now I seem to be getting along without having to enable XPath 3.0 or adapt Saxon… Heck, the reference finder even seems to find more nodes than before (and logically so I think, but with very exceptional xpath xpressions that I never saw in real life…


One important question though. Is the workaround above ‘safe’ or is there another way to get the name of an element?




Ronald van Kuijk



From: Michael Kay [mailto:mike@saxonica.com]
Sent: donderdag 9 augustus 2012 11:08
To: saxon-help@lists.sourceforge.net
Subject: Re: [saxon] exception with empty default namepace ("uri":local ...)


OK - it looks to me as if you've got some generated XPath that uses the "":amount syntax, and Saxon is not allowing this syntax unless XPath 3.0 is enabled; when you change the ExpressionParser to allow this syntax without the XPath 3.0 check, then it works. Which all seems quite reasonable. It's unfortunate that earlier releases of Saxon did allow this syntax even when XPath 3.0 wasn't enabled, but the current behaviour is correct.

Michael Kay

Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

saxon-help mailing list archived at http://saxon.markmail.org/