Subject: RE: [xsl] Re: The Perils of Sudden Type-Safety in XSLT 2.0 From: "Michael Kay" <michael.h.kay@xxxxxxxxxxxx> Date: Sat, 1 Mar 2003 20:19:37 -0000 |
Kurt Cagle wrote: > Personally, I think that maybe a type-safety attribute > sitting on the <xsl:stylesheet> node would do the trick. This > would instruct the processor to perform type-safety checking > if enabled, and would turn that feature off if not. This > would mean that non-type-safe code would be less safe but > probably more efficient. I have some sympathy with those who like the "weak typing" nature of XSLT 1.0, however, there are considerable difficulties making it work with the richer set of types available in XSLT 2.0, which are there for good reasons - people doing financial calculations, for example, don't like using floating point. There are many arbitrary rules in the type conversions that XPath 1.0 does, for example: a/@b = 3 tests if any of the nodes has the string value "3". (3.0 will not match) a/@b <= 3 tests if any of the nodes has a value that is numerically less than or equal to 3 (3.0 will match) a/@b+1 < 4 test whether the value of the first node is numerically less than 3; the other nodes are not considered. We have got used to these peculiarities and we tell new users that they are FAQs (implying they should know the answer). The difficulty we face with XPath 2.0 is that to handle a richer type system, including (a) more primitive types, and (b) more general collections, the number of such arbitrary rules would multiply to a point where not even the experts could be expected to remember them all. This is the basis of the decision in XPath 2.0 to move to stronger type rules. I have already started, in my own development, using version="2.0" to switch automatic type conversion off, and I am also starting to make a habit of declaring the types of parameters and variables. I find that the compile-time error messages this generates are a useful reminder of where I have invoked implicit conversions, and that writing the conversions explicitly makes the code more readable and less likely to contain bugs. Kurt suggests that automatic type conversion is likely to be more efficient. The opposite is the case. I don't think it's likely to make a big difference, but in general I think you can expect that with stronger typing, the code will run slightly faster. Saxon 7.4 is generating the code to do dynamic type checking and/or dynamic type conversion only in cases where static analysis shows this to be necessary, whereas earlier releases did the checking and conversion regardless. Michael Kay XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Sorting with unknown number o, Dimitre Novatchev | Thread | RE: [xsl] Re: The Perils of Sudden , Michael Kay |
[xsl] Sorting with unknown number o, Dimitre Novatchev | Date | RE: [xsl] OMR Mark for folding mach, Michael Kay |
Month |