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