Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#711 Incorrect analysis of PositionRange

v8.9
closed
Michael Kay
5
2012-10-08
2007-07-25
Michael Kay
No

Internally Saxon uses an expression called a PositionRange to represent a range of integers, especially when used as a predicate in a filter expression: for example the construct $x[2] is represented by a SliceExpression with a PositionRange as a subexpression. The analysis of a PositionRange (and hence of its containing expressions) is incorrect, in that it decides the expression depends on the context position.

The consequences of such an error in the analysis are difficult to predict or describe accuratly. In the case in question, the consequence was that an expression that expected the value of a variable to be held in a form suitable for indexing found at run-time that this was not the case, and had to convert the value, producing the warning message "*** Base value for indexed lookup is not indexable" to indicate that this situation is one that should never arise. This particular problem occurred in a path that is Saxon-SA only.

A patch to module net.sf.saxon.expr.PositionRange is in Subversion.

Discussion

  • Michael Kay
    Michael Kay
    2007-08-03

    Logged In: YES
    user_id=251681
    Originator: YES

    The patch was unfortunately incorrect and causes many expressions with predicates of the form xx[position() > 3] (with any comparison operator) to produce incorrect results. Indeed, the analysis given above is quite wrong: PositionRange in general does depend on the context position. The patch is being reverted in Subversion and the original bug will be reexamined.

     
  • Michael Kay
    Michael Kay
    2007-08-05

    Logged In: YES
    user_id=251681
    Originator: YES

    In fact the dependency analysis for PositionRange was correct. The error was in the class SliceExpression, which represents an expression of the form AAA[position()>6]. The is wrongly inferring a dependency on position() because it has a subexpression (a PositionRange) that depends on position. The correct solution is to mask out this dependency, as is already done for other similar constructs like FilterExpression.

    The problem can also be addressed at a different level. Inferring a dependency that's nto actually there should not cause problems. It's causing problems because LetExpression has decided earlier to use an indexed implementation of the variable, and then subsequently calls lazyEvaluationMode() which attempts to decide the evaluation mode, and this doesn't take account of the earlier decision.

    So two patches are being placed in Subversion: one to fix the dependency calculation in SliceExpression, and one to take account of the indexing decision when LetExpression determines its runtime evaluation mode.

     
  • Michael Kay
    Michael Kay
    2007-11-04

    Logged In: YES
    user_id=251681
    Originator: YES

    Fixed in 9.0.0.1