Subject: Re: [xsl] Using or ignoring Types in XSLT 2.0 / XPath 2.0 From: "Mike Haarman" <mhaarman@xxxxxxxxxxxxxxxxxx> Date: Tue, 13 May 2003 04:06:00 -0500 |
----- Original Message ----- From: "Andrew Watt" <andrew@xxxxxxxxxxxxxx> > You might want to take a look at the questions I posed on > public-qt-comments a day or two after the new Working Drafts came out and > the follow-up answers from David Carlisle and Michael Kay: > > http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0049.html > I have and I'll quote from them in a moment. > Values of the "untyped type" can be cast automatically to the desired type. > Then things work as if it had been typed in the first place, assuming that > the string which is of "untyped type" is castable to the type that the > function expects. That assumption of castability creates the potential for a class of errors that stylesheets were previously not susceptible to, correct? To complicate your *silly* example: <MyDate>Fred</MyDate> <MyDate>2003-5-15</MyDate> Its not clear to me how automatic casting operates over these elements. > 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? That can't be so heretical if there are limits on xdt:untypedAtomic. Is xdt:untypedAtomic ever anything more or less than a collection of unicode points? Mike Kay replied in the thread linked above: *No, all the functions are available. The only facilities that won't be available are those explicitly associated with schemas and complex types.* How is *won't be available* expressed by the processor when a function is presented with an argument it cannot coerce? *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.* I'll make time to begin experimenting with this. David Carlisle replied in the same thread: *So I think this means that If you use a date function on a string extracted from an untyped input doc, it will be coerced to a date type before calling the function.* Here is my narrative: I set out to write a stylesheet in XSL2 without reference to a schema. I hope to operate merely over the tree as exposed by axes and attributes, expecting only a well-formed instance. Is it merely irresponsible practice to make use of xdt: reliant functions of XPath in light of such requirements or am I limited to Andrew's *loosely typed profile* by the processor? Is this implementation specific behavior? And in light of the new range of failure this exposes, do we get *trys* with this shake? Mike XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Using or ignoring Types in XS, Andrew Watt | Thread | Re: [xsl] Using or ignoring Types i, Andrew Watt |
Re: [xsl] XSLT Language Grammar, Mike Brown | Date | RE: [xsl] XSLT In the Build Process, Jim Fuller |
Month |