[
Lists Home |
Date Index |
Thread Index
]
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/
|
