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
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