Project

Profile

Help

Forums » Help »

fn:compare() negative scenario

Added by Anonymous over 18 years ago

Legacy ID: #3454628 Legacy Poster: marcvc (marcvc)

Michael, we've found the following suspicious Saxon 8.6 (and other versions) behaviour. A negative scenario wrt. fn:compare(). for $i in doc("file1.xml")//text() return fn:compare($i,doc("file2.xml")//text()) Assuming that file2.xml contains more than 1 text node, we would have expected an error, but the query yields a result. Note that a query as follows does result in the expected error: XPTY0004: A sequence of more than one item is not allowed as the second argument of fn:compare() Thanks, Marc


Replies (1)

RE: fn:compare() negative scenario - Added by Anonymous over 18 years ago

Legacy ID: #3455530 Legacy Poster: Michael Kay (mhkay)

Thanks. A complicated one to explain (which probably means I'm not going to raise a bug entry for it). The expression doc("file2.xml")//text() is being moved out of the for loop into a generated variable, because it doesn't depend on the range variable; the evaluation of the generated variable incorporates the cardinality checking. When the argument to compare() comes to be evaluated, however, it's assuming that the value is a singleton and gets the first value of the variable without triggering the cardinality-checking code. It seems to be solved by deleting lines 75-76 of net.sf.saxon.value.Value which read } else if (value instanceof Closure) { return ((Closure)value).evaluateItem(context); But I haven't done a full regression test of that. Michael Kay

    (1-1/1)

    Please register to reply