----- Original Message -----
From: "Michael Kay" <mhk(_at_)mhk(_dot_)me(_dot_)uk>
With a Basic XSLT Processor (i.e. one that does not support schema
validation), the nodes in a source document will always be untyped. If
an attribute contains a dateTime, then it will be cast automatically to
an xs:dateTime if you use it in a function call where a dateTime is
required. So you can do things like:
get-year-from-dateTime(@date-of-birth)
This will fail with a run-time error if the attribute value is not
lexically a legal dateTime.
So that in the absence of a PSVI which has managed lexical correctness for me I
am still pfaffing with strings. I do not regard the necessity to learn a bit of
something about xsd: types to be an issue here. I am rather concerned that my
stylesheets will have to learn something about types.
This is a class of errors I'd as soon not fail on. In the construction of a set
of generic templates which will not operate over a valid instance, I will need
to check the lexical validity of a given cast in XSL, correct? At the least
this is a class of error it would be handy to catch and redirect.
Historically, the conventional wisdom is that validation is an expense to be
avoided in system design with XML. Validation for my current project is not
available to the production system but only turned on for development. My
concern is that in the WG's current model, validation becomes a necessity and
that a wedge is being driven between well-formed and valid XML.
Are there facilities that manage this problem that I am missing? Also, are
conforming XSL2 processors required to provide a *Basic XSLT Processor*?
Mike
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list