26606 2014-08-19 08:39:26 +0000 XT3TS: bug-1701 2015-05-06 21:16:21 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Test Suite Recommendation PC Windows NT CLOSED FIXED P2 normal --- 1 tim abel.online abel.braaksma mike public-qt-comments oldest_to_newest 110286 0 tim 2014-08-19 08:39:26 +0000 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) &gt; 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()]" 110287 1 mike 2014-08-19 10:16:01 +0000 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. 118724 2 mike 2015-03-20 15:13:21 +0000 Now fixed. 120173 3 abel.braaksma 2015-05-06 21:16:21 +0000 Was resolved > 30 days ago, closing.