RE: Re: What is the best way to cast integer to string
At 14:26 13/05/2003 +0100, you wrote: >A "Basic XSLT Processor" supports atomic values conforming to the >built-in types defined in XML Schema. So you can do things like
>xs:duration("P10H30M") + xs:duration("P12H15M")
>to add two durations.
In other words, to be able to use date / time / duration related functions a newcomer to XSLT 2.0 will need to learn how to write correct (lexical forms of) types such as xsd:date, xdt:yearMonthDuration and so on. I don't see that as an onerous burden. But I can't see how that minor acquisition of new information can be avoided either, except if the stylesheet author chooses to continue to use string-related functions to manipulate dates (as has been the case in XSLT 1.0).
With a Basic XSLT Processor (i.e. one that does not support schema validation), the nodes in a source document will always be untyped.
Is that correct?
As I read XSLT 2.0 (Section 21.1) element nodes processed by a Basic Processor are annotated with xsd:anyType and attribute nodes with xdt:untypedAtomic. So those nodes are typed, but in such a way as to leave pretty open how they can be used.
I would have expressed it as nodes in a source document will always be typed (as xsd:anyType or xdt:untypedAtomic in the case of a Basic XSLT 2.0 Processor) but they can be used as if they were untyped, assuming they meet the not very onerous lexical constraints.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format