xsl-list
[Top] [All Lists]

Re: [xsl] Avoiding boneheaded mistakes in XSLT?

2010-12-28 17:07:46
There are indeed languages where these subtle traps happen more frequently than with others. I remember when I started coding C++ in 1995, there were really frustrating moments. When I started using Java, these frustrating moments dramatically decreased, and this is not solely attributable to my overall programming skills that have developed in the meantime. I found that although Java code is sometimes very verbose and inelegant (as opposed to Ruby), there are few bonehead or subtle but undiscoverable mistakes to be made.

XSLT is sometimes verbose (in a different way than Java, but anyway) and prone to sublte traps (like C++), but you can code quite elegantly (like Ruby; or rather, if you ever tried Ruby’s XML processing facilities, XSLT is as elegant as only XSLT is when it comes to processing XML). Experience will help discover or avoid the traps quickly. Experience will particularly tell you that a resolute debugging strategy is indispensable. I didn’t find XSLT’s learning curve to be steeper than other languages’. The messages I get from the processor/compiler are quite useful for debugging purposes. (The latter is true only for XSLT 2+.)

I once assembled a list of questions to ask yourself if a template obviously didn’t match:
http://www.biglist.com/lists/lists.mulberrytech.com/xsl-list/archives/201001/msg00257.html

Is there a Wiki around so that we can collect our wisdom in it?

Gerrit


On 28.12.2010 23:35, David Sewell wrote:
This is to some extent a general programming question, as it is possible
with any programming language to write something that is syntactically
legitimate (i.e., does not throw a compile- or run-time error) but fails
to produce expected results because of a mistake in logic or something
else. I'm sure we've all had the experience of beating our heads against
a programming failure that turns out to be the result of a very simple
(aka "boneheaded") mistake that seems obvious when found. It seems to me
that this is perhaps more likely with XSLT/XPath than some other
environments, because of (1) the general verbosity of expression, and
(2) the many complexities of return values when you're working with a
combination of XML documents and fragments, and sequences of nodes
and/or atomic values.

Over the last few days I've been working on some especially complex
transforms and have lost more time that I'd like owing to some of these
simple mistakes. Not the first time by a long shot I've made them, either. For
example:

1. In an XPath expression, using "something/node" where I wanted
"something/node()" [ditto text vs. text()]: always means zero results and
can drive you crazy if you don't notice the missing parentheses;

2. Using xsl:copy-of instead of xsl:apply-templates in a case where
recursive processing is in fact needed on the item in question;

3. Using xsl:value-of when you really need xsl:copy-of for a variable
that is a sequence;

4. Bad logic with xsl:analyze-string, putting processing into
xsl:non-matching-substring that should have gone into
xsl:matching-substring or vice versa.

Do these sound familiar? Other favorite traps?

Has anyone come up with a useful list of "things to check any time my
code is not working the way it should"?

DS



--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
gerrit(_dot_)imsieke(_at_)le-tex(_dot_)de, http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
Thomas Schmidt, Dr. Reinhard Vöckler

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