xsl-list
[Top] [All Lists]

RE: Re: The Perils of Sudden Type-Safety in XSLT 2.0

2003-03-01 13:19:37
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



<Prev in Thread] Current Thread [Next in Thread>