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
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