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).
If you want to add numbers you are going to have to learn how to write
numbers. If you want to add durations you are going to have to learn how
to write durations - something which I have not yet mastered :-)
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?
I'm using "untyped" as a convenient shorthand for "typed as xs:anyType
in the case of elements or xs:untypedAtomic in the case of attributes."
There is a proposal in the works to distinguish "xs:anyType" from
"xs:untypedComplex" in the same way as we currently distinguish
"xs:anySimpleType" from "xs:untypedAtomic".
Michael Kay
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.
Andrew Watt
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list