[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Ten new XQuery, XSLT 2.0 and XPath 2.0 Working
Hi Liam, > The useful thing here is that this can be detected easily at > "compile time". Although your example is clearly a bug, consider the > common error, > concat(page, position(), ".html") > instead of > concat("page", position(), ".html") > > which does the "wrong thing" silently in XSLT 1, and is now an error > (assuming there's no conveniently located page element of course!) I agree that an XSLT lint that could detect these kinds of mistakes would be wonderful. Another stupid error that I see every now and then is using quotes around a variable name, as in "$foo" rather than just $foo -- a lint that could detect that and check that it was actually what you wanted to do would be very useful. However, your above example will continue to do the "wrong thing" silently in Basic XSLT 2.0 since the processor needs to know that the context node cannot have a <page> element child in order to work out that there is a bug in the code, and that information is only available if you have typed nodes. Indeed, even with Schema-Aware XSLT 2.0, you would only get an error with the above if the context node were explicitly typed somehow. For example, if you just had: <xsl:template match="foo"> <xsl:value-of select="concat(page, position(), ".html")" /> </xsl:template> a processor wouldn't be able to tell that this was an error because there's no indication of the type of the <foo> element matched by the template. >> If the upgrade pathway from XSLT 1.0 / XSLT 2.0 for existing XSLT >> users is smooth, I find it difficult to see any reason for staying >> with XSLT 1.0. The extra functionality in XSLT 2.0 is very >> attractive. > > There's no reason for people to change, if wht they have is working. > On the other hand, I routinely run XSLT stylesheets through at least > two implementations (usually saxon and xsltproc) to maximise the > chances of finding errors. Better error checking, and *especially* > more static analysis ("compile time" errors, if you like), will be > wonderful. More helpful error checking in XSLT would certainly be useful. I came across an interesting article that described the benefits of strong typing done well at http://perl.plover.com/yak/typing. I thought the following point was particularly well made: --- The problem with all this [typing of aggregate values] was that it turns out to be more complicated to get `right' than scalar types were. What do I mean by `right'? Well, remember that the goal here is to enable compile-time checking of the soundness of your program. If it compiles, and there are no type errors, you'd like to be able to feel safe about your code. Now there are two kinds of possible failures here. There might be some real type error that is not caught by the compiler; that's a `false negative'. It's bad because then you run your program and it does something bizarre, like interpreting eels as the number 1.87292264408661e+31. It's also possible that the compiler might report an error where there isn't one; that's a `false positive'. It's also bad because you are trying to do something reasonable, and the compiler refuses to compile your program because it is afraid something will go wrong. Another way in which this is bad is that it encourages you to ignore the correct error messages when they do appear---that's the `Boy Who Cried Wolf' syndrome. The use of warning signs shall be kept to a minimum as the unnecessary use of warning signs tends to breed disrespect for all signs. (Manual on Uniform Traffic Control Devices, Millennium Edition, section 2C.02.) --- In other words, type checking that helps you fix errors in your code (in the algorithm that you're using) is good; type checking that just stops you from doing reasonable things is bad. > Especially errors in parts of my style sheet that were not reached > with my test data. Note that static type checking (at least as defined in XPath 2.0) is not required in XSLT 2.0 processors. XSLT 1.0 is designed so that all dynamic errors are recoverable: thus if you don't get an error with your test data it's pretty much guaranteed that you won't get an error with your real data. (Of course you can still get an unintended result, but no amount of checking, static or otherwise, can prevent that.) In XSLT 2.0, some errors can only be detected at run time, so it is no longer the case that if your test data works with a stylesheet you know that you will not get an error with any real data. > And if the result is also that XSLT transformations happen more > quickly, more efficiently, especially on large amounts of data, > that's a pretty good win. Unfortunately this promise is coupled with making writing XSLT transformations much more of a burden, and disproportionately so for those users who want to use XSLT 2.0 in a simple, schema-less way since they get hardly any benefit from error checking. I fear that many XSLT 1.0 users will get so irritated by the hoops they have to jump through writing Basic XSLT 2.0 that they will never get to the more powerful and helpful features of Schema-Aware XSLT 2.0. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
|
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
|