Thanks for reporting this. The Saxon implementation is not quite up-to-date with the latest spec in this area, and I will make sure the documentation is updated to reflect this.
 
In fact, your note has prompted the observation that the definition of the "eq" operator in XPath has changed since this text in the XSLT specification was written, and we (the WG) need to review whether it still has the effect that was intended, especially as regards the handling of untypedAtomic key values. For example, the current spec implies that if the key says use=@code and the document is untyped, then the call key('k', 1234) will never match anything, which is a bigger incompatibility from 1.0 than was intended or documented.
 
Michael Kay


From: saxon-help-admin@lists.sourceforge.net [mailto:saxon-help-admin@lists.sourceforge.net] On Behalf Of Alexander Shrago
Sent: 29 April 2004 10:07
To: saxon-help@lists.sourceforge.net
Cc: Alexander Makanin
Subject: [saxon] saxon xslt2.0 bug

according XSL Transformations (XSLT) Version 2.0 (W3C Working Draft 12 November 2003):

"An XSLT 1.0 processor compared the value of the expression in the use attribute of xsl:key to the value supplied in the second argument of the key function by converting both to strings. An XSLT 2.0 processor compares the values as supplied. In the most common case, where the values of the keys are untyped atomic nodes, this will give the same results. In cases where the key value is a more specific type (for example xs:string or xs:integer) a match will be obtained only if the value supplied to the key function is of a comparable type. For example if use="string-length(@x)" is specified, then the function call key('k', 2) will give the same results in XSLT 2.0 as with XSLT 1.0, but the call key('k', '2') will always return an empty sequence with XSLT 2.0."

We test this sample, but
call key('k', '2') return the same result as call key('k', 2), not empty sequence !