[F+O] Type conversion in concat()

I have been testing the example stylesheets in my XSLT Programmer's
Reference under XSLT 2.0. Three or four of the examples (so far) have failed
with the same error: concat() in XPath 2.0 requires the arguments to be
supplied as strings. The most common examples are things like:

 

<title><xsl:value-of select='concat("Chapter ", position())'/></title>

 

It doesn't fail under backwards compatibility mode, of course. But that's
not good enough, we want to encourage users to run in pure 2.0 mode whenever
possible.

 

It doesn't seem reasonable here to ask users to write string(position()).
How can we justify asking them to make such changes - where are the
benefits? 

 

It's not required in XQuery, whose equivalent construct is:

 

<title>Chapter {position()}</title>

 

If this can implicitly cast to string, why can't concat()?

 

Java has a general policy of strict typing, but it makes an exception for
the string concatenation operator, which casts its operands implicitly to
strings. In XPath, concat() is already special-cased by allowing a variable
number of arguments. 

 

I believe we should change the signature of concat() so its arguments are
defined as anyAtomicType, and are implicitly cast to strings.

 

Michael Kay