RE: [xsl] Re: What is the best way to cast integer to string in X SLT2?
Subject: RE: [xsl] Re: What is the best way to cast integer to string in X SLT2?|
From: Andrew Watt <andrew@xxxxxxxxxxxxxx>
Date: Tue, 13 May 2003 15:21:02 +0100
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