One thing I do really dislike about XSLT, at least from what I
understand, is there doesn't seem to be a way to write robust code in
XSLT; if my input XML is off by a bit (i.e. well-formed but not
validated by a schema), or if I make a boneheaded change to
the XSL, the
transform may not output what I expect but there's little way
for me to
catch the error without painstaking proofreading after each transform
(scenario: after somethings been printed for a while; opps, looks our
XSL forgot to include that chapter!)
This is the main motivation behind the introduction of schema-awareness in
XSLT 2.0.
Firstly, you can validate the output against a schema. Sometimes you will
get compile-time error messages telling you that the stylesheet cannot
possibly produce valid output; more often you will get run-time error
messages telling you that line 1234 of the stylesheet is trying to output
something that's invalid (or failing to output something that's required).
My experience is that this greatly speeds up the debugging cycle.
Secondly, you can validate the input against a schema, and define your
template rules in terms of schema types. For example <xsl:template
match="schema-element(invoice)"/>. This enables the XSLT processor to do a
lot of compile-time checking of your stylesheet code, for example it can
spot path expressions that could never select anything.
Give it a try (follow the link below).
Michael Kay
http://www.saxonica.com/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--