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.
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 22.214.171.124 version there)
The same xpath was returned in Saxon 126.96.36.199 in which it worked. In Saxon 188.8.131.52 it was
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 ;
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
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.
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
saxon-help mailing list archived at http://saxon.markmail.org/