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


On 09/08/2012 01:13, Ronald van Kuijk wrote:

Digging into the dungeons of some good frameworks is always a good way to learn things, but it coding in java, xpath itself, writing parsers, whatever.

 

The instance(‘xxx’) function might be causing trouble, but I think other functions are as well. That might also be only with functions in the xforms namespace, will check that out.

 

|| I can't see any way the tokenizer can return a name in the format {}amount unless there is a string literal in the source immediately followed by a colon.

 

Well, if parsing an expression like ../child::element('':amount) would lead to this, we might have found a cause. This is what the tokenizer was processing before returning {}amount. The original expression (below) is parsed into an expression where this is part of. For the xpath engine, each xpath is ‘split’ into so references (I heard you talked about this to Joern Toerner at XML Prague) that each will be converterted into parsed expression that will be put into a cache, to be used to decide what nodes should be updated if such a reference changes.

 

The additional xpath functions that are not available in xpath are added via function libraries. (keep in mind that the code referenced below is for saxon 9.2.1.5 but the basics have not changed)

 

https://github.com/betterFORM/betterFORM/blob/development/core/src/main/java/de/betterform/xml/xpath/impl/saxon/XPathCache.java#L50

 

These are added to the “IndependentContext” and at the same time, the default function namespace is set to the xforms namespace. This all is done in:

 

https://github.com/betterFORM/betterFORM/blob/development/core/src/main/java/de/betterform/xml/xpath/impl/saxon/XPathCache.java#L185

 

One thing that is done is that in the function library for the additional xforms functions also the normal xpath functions are added:

 

https://github.com/betterFORM/betterFORM/blob/development/core/src/main/java/de/betterform/xml/xforms/xpath/saxon/function/XFormsFunctionLibrary.java

 

 

Your confusion about my statement of parsing vs evaluating was valid. I was put of on the wrong foot because an evaluated expression (a saxon Expression object) was already available, so I thought it went wrong when evaluating. What I did not see (stupid me, sorry) was that this expression was going to be split into references… It fails, as mentioned above) when parsing these individual references. So you are right…  Here you see the order of which the tokenizer parses the suspicious element (not sure where the loop of 2/0 comes from. Did not see that earlier on (afaik).

 

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

 

Token: 206[..]

Token: 2[/]

Token: 36[<axis>] child

Token: 69[<node-type>()] element

Token: 201[<name>] {}amount

Token: 2[/]

Token: 0[<eof>]

Token: 2[/]

Token: 0[<eof>]

Token: 2[/]

Token: 0[<eof>]

Token: 2[/]

Token: 0[<eof>]

Token: 2[/]

Token: 0[<eof>]

Token: 2[/]

Token: 0[<eof>]

Token: 2[/]

Token: 0[<eof>]

 

 

Hope this helps… Since it might be that I made an accidental error in the reference parser, but still strange that it in the end it works if I comment out a specific if-then in the ExpressionParser.

 

Cheers,

 

Ronald van Kuijk

 

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

 


Thanks for your sterling efforts to get to the bottom of this.

First, you're right that 9.4 is still supporting the "uri":local syntax rather than the newer Q{uri}local.

I suspected that the function call instance('xxx') might be causing problems because of the conflict with the "instance of" operator. So I did a modified build in which the instance() function was defined, and it ran without trouble.

I can't see any way the tokenizer can return a name in the format {}amount unless there is a string literal in the source immediately followed by a colon.

I'd be interested to know how you enable Saxon to recognize the instance() and current() functions which are not normally supported in XPath.

We should probably change the code so that the tokenizer doesn't recognize "uri":local unless the parser is going to accept it, but that doesn't seem to be at the root of the problem. In your debugging, did you see what path the tokenizer was taking before it returned {}amount?

I'm confused by this statement: "When the expression is build, nothing fails but when it is actually evaluated, it fails with the exception above.", since the error message is clearly one that can only arise during XPath parsing. I wonder if it's the case that the instance() function invokes some dynamic XPath parsing?

Michael Kay
Saxonica

On 08/08/2012 10:21, Ronald van Kuijk wrote:

string(../amount * instance('convTable')/rate[@currency=current()/../currency])

 



------------------------------------------------------------------------------
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