Bug #3384: Context item for attribute axis step says it's missing when it should not be - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #3384

closed

Context item for attribute axis step says it's missing when it should not be

Added by Priscilla Walmsley over 7 years ago. Updated over 7 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

Internals

Sprint/Milestone:

Start date:

2017-08-10

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

9.8

Fix Committed on Branch:

9.8

Fixed in Maintenance Release:

9.8.0.4

Platforms:

Description

This query:

xquery version "3.0";

let $prods := doc("catalog.xml")//product

for $prod in $prods

where $prod << $prods[@dept = $prod/@dept][last()]

return $prod

returns:

XPDY0002: The context item for axis step attribute::attribute(Q{}dept) is absent

This query used to work on previous versions of Saxon.

Files

Download all files

catalog.xml (580 Bytes) catalog.xml		Priscilla Walmsley, 2017-08-10 21:49
context-error.xq (189 Bytes) context-error.xq		Priscilla Walmsley, 2017-08-10 21:49

Actions

Copy link

Updated by Michael Kay over 7 years ago

Thanks for reporting it. The -explain output gives a clue to what is happening:

OPT : At line 4 of file:/Users/mike/Desktop/temp/context-error.xq
OPT : Collapsed redundant for expression $prod
OPT : Expression after rewrite: $prods[. << (lastOf(IndexedFilterExpression($prods, data(@dept), data(attribute::attribute(Q{}dept)))))]
OPT : At line 5 of file:/Users/mike/Desktop/temp/context-error.xq
OPT : Lifted (lastOf($prods[(:indexed:)@dept=@dept])) above ($prods[. << $vv:v0]) on line 4
OPT : Expression after rewrite: let $Q{http://saxon.sf.net/generated-variable}v0 := lastOf(IndexedFilterExpression($prods, data(@dept), data(attribute::attribute(Q{}dept)))) return ($prods[. << $Q{http://saxon.sf.net/generated-variable}v0])
<query>
  <globalVariables/>
  <body>
    <let baseUri="file:/Users/mike/Desktop/temp/context-error.xq"
         ns="fn=~ xs=~ saxon=~ err=http://www.w3.org/2005/xqt-errors local=http://www.w3.org/2005/xquery-local-functions xsi=~"
         line="3"
         var="prods"
         as="element(Q{}product)*"
         indexable="true"
         slot="0"
         eval="3">
      <slash simple="1">
        <fn name="doc">
          <str val="catalog.xml"/>
        </fn>
        <axis name="descendant" nodeTest="element(Q{}product)"/>
      </slash>
      <let xmlns:vv="http://saxon.sf.net/generated-variable"
           line="5"
           var="vv:v0"
           as="element(Q{}product)?"
           slot="1"
           eval="13">
        <lastOf>
          <indexedFilter2 comp="CCC" flags="u">
            <varRef role="base" name="prods" slot="0"/>
            <attVal role="use" name="Q{}dept" chk="0"/>
            <data role="search">
              <axis name="attribute" nodeTest="attribute(Q{}dept)"/>
            </data>
          </indexedFilter2>
        </lastOf>
        <filter line="4" flags="">
          <varRef name="prods" slot="0"/>
          <precedes line="5" op="&lt;&lt;">
            <dot type="element(Q{}product)"/>
            <varRef name="vv:v0" slot="1"/>
          </precedes>
        </filter>
      </let>
    </let>
  </body>
</query>
Type error on line 5 column 43 of context-error.xq:
  XPDY0002: The context item for axis step attribute::attribute(Q{}dept) is absent
Query failed with type error: The context item for axis step attribute::attribute(Q{}dept) is absent

It seems that in constructing the indexed filter expression, a dependency on the $prod variable has been overlooked at some stage.

Actions

Copy link

Updated by Michael Kay over 7 years ago

The cause of the problem appears to be that the operand usage template for IndexedFilterExpression is incorrect. The expression has three operands: the sequence to be indexed, the "use" expression used to calculate the key, and the "search" expression providing the actual key value. The "use" expression is correctly classified as being focus-dependent on the sequence expression, but the "search" expression has the same classification, which is incorrect.

Actions

Copy link

Updated by Michael Kay over 7 years ago

Category set to Internals
Status changed from New to Resolved
Assignee set to Michael Kay
Priority changed from Low to Normal
Fix Committed on Branch 9.8 added

Fixed after making several changes:

(a) the operand properties for the search operand of an IndexedFilterExpression are corrected to indicate that it is evaluated with the same focus as the containing expression. This property is used by the new generic loop-lifting code in 9.8 to work out how far an expression can safely be lifted out of containing looping constructs

(b) the type-checking code for IndexedFilterExpression is similarly changed to use the right context item type for evaluating the type of the search expression (I don't think this was actually the cause of the problem in this case)

(c) the optimization code for IndexedFilterExpression, which reverts it back to an ordinary filter expression in cases where the variable has been inlined (typically because its value is known at compile time) is corrected to handle the case where the search expression is focus-dependant. This case isn't exercised by this test, and I'm not sure how to force execution of this path, but the change is clearly necessary.

Actions

Copy link