[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
----- Original Message ----- From: "Andrew Watt" <andrew@xxxxxxxxxxxxxx> > 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. I am less concerned about attaining such basic knowledge than I am that my stylesheets will need it. > ><MyDate>Fred</MyDate> > ><MyDate>2003-5-15</MyDate> > > > >Its not clear to me how automatic casting operates over these elements. > > The first would generate an error, in my expectation. It would not in XSLT 1.0. This is my concern. Do I need to start catching lexical errors in my stylesheets? > 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. And this is where I get hung up. XSLT v1.0 this is just crap data that needs proofreading. In XSLT v2.0, even for a Basic XSLT Processor, this is a run-time failure that I can't recover from. Somebody else must see this a problem or I am missing something big somewhere in the literature. > > 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. In the absence of PSVI annotation, what is it? A great comfort of XSL 1.0 is that everything is either a string or it is a nodeset that has a straightforward string value: text(). Can I starts-with() an xdt:untypedAtomic or must it be cast as a string? > 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. I think that this is mistaken. Simple, happily munged strings of characters do not generate run-time failure in XSLT 1.0. Everything I've read so far indicates to me that even a Basic XSLT Processor written to the current draft must fail on lexical errors. Again, I am less concerned about *doing it the old way* or *avoiding complexity* than I am about exposing new run-time errors. Is this a job for fallback processing? 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
|