Re: Re: What is the best way to cast integer to string

----- Original Message ----- 
From: "Michael Kay" <mhk@xxxxxxxxx>

> 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