Thanks a lot Jeni and Andrew,
This is a good example of what I meant during my talk at XML Europe
about life getting harder for XSLT users because of the strong typing
in XPath 2.0. XPath 2.0 allows implicit casting:
1. from xdt:untypedAtomic (the type of untyped nodes) to any atomic
type
2. from any atomic type to its base type (up the atomic type
hierarchy)
3. from xs:decimal (and its subtypes) to xs:float or xs:double and
from xs:float to xs:double
As you say, it is possible to cast values of most types into a string
(exceptions are xs:QName and xs:NOTATION), but in terms of the type
hierarchy used by XPath 2.0, it is not the case that every type is
derived from xs:string. (I guess you're aware of the recent XML-Dev
discussion on this topic.) So you have to perform the casting
explicitly.
Do any examples exist when such implicit casting would be
dangerous/counter-intuitive? If not, then it would be very useful to allow
implicit casting to string. In C++ one can specify a constructor that takes
a single argument og another type, e.g.:
class complex
{
double re, im;
public:
complex (double r) : re(r), im(0) {}
};
Then the programmer simply writes:
complex a = 7;
instead of
complex a = complex(7);
In cases like the current one I think such "conversion constructors" should
be specified in the XPath data model. This makes writing and understanding a
program much more easier.
2. My current solution is to use
string(position())
Is this the best/recommended solution?
Yes. For atomic values like the integer returned by position(), it
returns the same as xs:string(position()); the latter is just longer
and requires an extra namespace declaration.
Thanks!
=====
Cheers,
Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list