This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I can't see anything in the specification to justify the expected behaviours of test extvar-def-016a & 016b. Specifically, I'm looking at text in 4.17 Context Item Declaration. extvar-def-016a: declare variable $y := (<a>1</a>,<a>2</a>,<a>3</a>,<a>4</a>,<a>5</a>,<a>6</a>,<a>7</a>,<a>8</a>,<a>9</a>,<a>10</a>); declare context item := $y[3]; declare variable $x external := fn:position(); $x The test expects fn:position() to be 3. While I can see where the expected result comes from (the context item points to the third item in $y), I can find no text which persuades me that evaluating $y[3] leaves the formatl semantics variable $fs:position as 3. extvar-def-016b: declare variable $y := (<a>1</a>,<a>2</a>,<a>3</a>,<a>4</a>,<a>5</a>,<a> 6</a>,<a>7</a>,<a>8</a>,<a>9</a>,<a>10</a>); declare context item := $y; declare variable $x external := fn:last(); $x The test expects fn:last() to be 10. Again, it's clear where this expected result comes from (count($y)), but I can find no text which leads me to believe that assigning $y to the context item will leave the formatl semantics variable $fs:last as 10. This test also contains a type check error. The context item's type may only be an ItemType, i.e. quantifier 1. In this test, $y is bound to a sequence of 10 elements. Therefore evaluating the context item would result in a type check error. Thus this query should expect XPTY0004. I believe that in the above, fn:position() and fn:last() can only ever return 1 (if the context item is defined) or raise an error (if the context item is not defined). However, since the query doesn't require the evaluation of the context item, it may also expect 1. Perhaps it might be preferable to consider the context item as undefined, and therefore fn:last() would raise XPDY0002.
I'm changing this to a bug on the spec, since the spec says absolutely nothing to help one decide what the result of this test should be.
Thanks. I had raised Bug 16035 against the specification, so I'm marking this as a duplicate. *** This bug has been marked as a duplicate of bug 16035 ***