I was trying this but missed the casting to the NameTest to get to the NamePool…

 

Thanks

 

From: Michael Kay [mailto:mike@saxonica.com]
Sent: vrijdag 10 augustus 2012 7:46
To: saxon-help@lists.sourceforge.net
Subject: Re: [saxon] 9.4.0.4 exception with empty default namepace ("uri":local ...)

 

I think you have to first decide which kind of NodeTest it is. If it's a NameTest (as in this case), then you can use getFingerprint() to get the fingerprint, and go to the NamePool to get the local name and URI corresponding to this fingerprint.

Michael Kay
Saxonica

On 09/08/2012 22:09, Ronald van Kuijk wrote:

Thanks, I already suspected something like this, getting to grips with code developed by someone else takes time (code in betterForm that is). But still it is a bit strange if you run in XPath2 modus that you get ‘toString()’ for diagnostics in an XPath3 version ;-)

 

I Have been working on composing it on a different way and that seems successful. But then I have one question left to get rid of using the toString() on NodeTest:

 

What if I have an AxisExpression, how do I get the (local) name of a node? There does not seem to be anything on the AxisExpression, NodeTest etc other than parsing the ‘toString()’

 

Thanks in advance.

 

Ronald van Kuijk

 

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

 

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
Saxonica

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

Hi,

 

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 9.2.1.5 version there)

 

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

 

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

 

So if

 

../child::element('':amount)

 

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

 

nodeTest.toString()

 

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

 

                        result.append("element(");

                        String nt = nodeTest.toString();

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

                        int endName = nt.length() -1 ;

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

                        result.append(", ");

                        result.append(nodeTest.getContentType().getDisplayName());

                        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?

 

Cheers,

 

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] 9.4.0.4 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
Saxonica







------------------------------------------------------------------------------
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/
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help 

 




------------------------------------------------------------------------------
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/
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help