Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Using or ignoring Types in XSLT 2.0 / XPath 2.0
 That assumption of castability creates the potential for a class of errors that Yes, I think so. It's partly why I said in an earlier post (I can't remember which list) that, for example, someone wanting to make use of the new date / time function must attain *some basic* knowledge of at least the lexical form of date types. To complicate your *silly* example: Hey, come on it wasn't *that* silly. <grin/> <MyDate>Fred</MyDate> <MyDate>2003-5-15</MyDate> The first would generate an error, in my expectation. The second probably would generate an error too, I think. Why? Because xsd:date is expecting CCYY-MM-DD and your example supplies only CCYY-M-DD. I just tried it in Saxon 7.5 and it complained it couldn't convert "integer" (not sure where it got that from) to "date". But it gives the same error message for 2003-05-15, so maybe xdt:untypedAtomic isn't fully implemented in Saxon 7.5 yet. But <MyDate>2003-05-15</MyDate> should, in my expectation, be processed transparently if everything works as it is claimed to work. > A (heretical?) thought that is beginning to float around in my mind ... > Dave Pawson may approve of this :) .... is why can't we just treat untyped > strings (which the WD proposes are treated as xdt:untypedAtomic) as ... > well .... xsd:string types? I guess it depends on what you mean by "limits". I don't know a way to cast "Fred" to a meaningful date. I suspect you don't either. So there *are* limits but not specifically of the xdt types. Is xdt:untypedAtomic ever anything more or less than a collection of unicode points? I think the WG will tell you that they are different and that xdt:untypedAtomic is a collection / sequence of code points which has been annotated as xdt:untypedAtomic. Whether you accept that that is genuinely something different is a separate question, in my view. Mike Kay replied in the thread linked above: Judging by initial experience of Saxon 7.5 it says it can't do it and the transformation won't be carried out. But Saxon 7.5 documentation is explicit that many aspects of typing are not yet implemented. *It is described in the "Conformance" section of the XSLT specification. Obviously, we hope that we've got it right and that it is practical and useful. It actually corresponds fairly closely to the subset of the spec implemented in Saxon 7.5, so there is some opportunity for users to give us practical feedback on whether it works.* Good. It will be useful to trade experiences. David Carlisle replied in the same thread: I *think* that what worked transparently before will work transparently in XSLT 2.0. At least that is what I understand the WG to be saying. So, if for example, you want to manipulate dates as strings ... or do I mean strings as dates? :) ..... and play around with substrings to format a date then you will still be able to do as you did in XSLT 1.0 (without having to think about W3C XML Schema datatypes), but if you want to be able to use the new XPath 2.0 date / time / duration functions you will need at least a basic understanding of how these "types" are expected to look when they are untyped strings. And in light of the new range of failure this exposes, do we get *trys* with this shake? Not as far as I am aware. Andrew Watt 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
|
