RE: The Perils of Sudden Type-Safety in XPath 2.0

> My question is: Isn't there any way simply to nlock all these 
> type checking, please?

I think it would be technically possible to continue implicitly casting
arguments to function calls so long as you abandon hope of ever
supporting polymorphic functions. It's not really possible with
operators, because the language would be completely crippled if
operators weren't polymorphic. XPath 1.0 has some pretty arbitrary rules
for how operands are converted, and I don't think this ad-hoc approach
scales to a system with a richer set of data types.

If you don't use types (i.e. schemas) in your source documents, then you
do get implicit casting on function calls, which is what you are asking
for.

> 
> But XSLT is *not* Haskell. Introducing such strong type 
> checking into XSLT make it almost impossible to work (if even 
> Jeni has such difficulties. then no mortal XSLT programmer 
> would be able to do anything at all), will decrease to zero 
> its users population and will change XSLT into something 
> completely different, which is not XSLT any more.
>
It's certainly a fairly radical change, and a more radical change than I
felt was wise when we embarked on it, but I personally think it's a
change for the better, and that people will not actually find the
transition that difficult.

We're talking here about a bug in the spec. Don't extrapolate too much
from that.

Michael Kay
Software AG
home: Michael.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx 
 


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list