Subject: Re: [xsl] The Perils of Sudden Type-Safety in XPath 2.0 From: Dimitre Novatchev <dnovatchev@xxxxxxxxx> Date: Wed, 19 Feb 2003 03:11:07 -0800 (PST) |
Jeni said: "The backwards compatibility flag *should* make expressions that are legal in XPath 1.0 do the same thing in an XPath 2.0 processor as they do in a XPath 1.0 processor. It should make expressions that are not legal in XPath 1.0 work roughly in the way that you'd expect them to were the XPath 1.0 rules extended into XPath 2.0, though as you've found you can't rely on this." Then: "Hmm... Interestingly in the light of what I said above, this seems to work if version="2.0" but not if version="1.0". The signature for string-pad() is: string-pad($padString as xs:string, $padCount as xs:integer) as xs:string? It works if version="2.0" because the type of the value of the @indent attribute is xdt:anyAtomicType, and when you pass a value of type xdt:anyAtomicType as an argument to a function it just gets converted automatically to the required type for the argument. So in this case the xdt:anyAtomicType value from the indent attribute gets converted to an xs:integer. On the other hand, if version="1.0" and the backwards compatibility flags apply then a numeric required type for the argument entails converting the argument to a xs:double value. As you've found, the xs:double value then can't be automatically converted to an integer, which is why you need the explicit cast. This isn't an issue with the XPath 1.0 functions because they all expect doubles, but as you've found, several of the new functions only accept integers. (FWIW, I thought that floor(), ceiling() or round() might help here, but they all return doubles, I think for compatibility with XPath 1.0, so that they can return NaN.)" Kurt said: "I've worked with XPath for the last five years (counting the time very early on when it was a very different looking animal), and I think I've run into maybe three times in that period where having type-casting would have made things easier, and that principally because XSL lacked certain pieces which are finally coming into play in XSLT 2. When you add type you increase the complexity of the applications with relatively little beneft, UNLESS you are looking for ways to build a bundled data-aware object. In other words, the principal driving requirements for PSVI can be traced back to trying to turn XML into an OOP object. This can certainly be done, but at the cost of losing much of the flexibility that makes XML so useful." The difficulties that even Jeni has prove Kurt's point. My question is: Isn't there any way simply to nlock all these type checking, please? Don't understand me wrong -- I do not need to be convinced and persuaded about the benefits of having a strong type checking system. I admire Haskell, which has it. 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. Do the authors of this beast really listen to what we are saying? Do they respect the XSLT programmers' community? Will XSLT 2.0 really be XSLT? ===== Cheers, Dimitre Novatchev. http://fxsl.sourceforge.net/ -- the home of FXSL __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] The Perils of Sudden Type, Martinez, Brian | Thread | RE: [xsl] The Perils of Sudden Type, Michael Kay |
Re: [xsl] The Perils of Sudden Type, Jeni Tennison | Date | [xsl] xslt coding conventions, Andrew Welch |
Month |