This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The result of this test depends on the order of evaluation. e.g. in <xsl:variable name="won" select="count($matches[team=$this][number(team[.=$this]/@score) > number(team[.!=$this]/@score)])"/> A processor is free to reorder the predicates. Doing so can result in a type check error in the call to number(). Quoting XPath 3.0: "The expression in the following example cannot raise a casting error if it is evaluated exactly as written (i.e., left to right). Since neither predicate depends on the context position, an implementation might choose to reorder the predicates to achieve better performance (for example, by taking advantage of an index). This reordering could cause the expression to raise an error. $N[@x castable as xs:date][xs:date(@x) gt xs:date("2000-01-01")] To avoid unexpected errors caused by expression rewrite, tests that are designed to prevent dynamic errors should be expressed using conditional expressions. For example, the above expression can be written as follows: $N[if (@x castable as xs:date) then xs:date(@x) gt xs:date("2000-01-01") else false()]"
Yuk, I always hated that rule, which was put in the spec for the benefit of implementors who want to translate XPath into SQL (and certainly not for the benefit of users). But it's there, so I guess we have to live with it.
Now fixed.
Was resolved > 30 days ago, closing.