Re: Avoiding boneheaded mistakes in XSLT?

> Do these sound familiar? Other favorite traps?

I think that one of the most common and difficult (at times with
almost unexplainable behavior) problem is the failure to provide
templates match certain nodes.

A good solution is to provide a "catch-all" template, for example:

<xsl:template match="*" priority="-20">
  <xsl:message>
    ERROR: Unmatched element: <xsl:value-of select="name()"/>
  <xsl:message>
</xsl:template>

This signals explicitly in any case when the node-list of an
<apply-templates> instruction contains an element that isn't matched
by a more specific template.


--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
Facts do not cease to exist because they are ignored.



On Tue, Dec 28, 2010 at 2:35 PM, David Sewell <dsewell@xxxxxxxxxxxx> 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
>
>
> --
> David Sewell, Editorial and Technical Manager
> ROTUNDA, The University of Virginia Press
> PO Box 400314, Charlottesville, VA 22904-4314 USA
> Email: dsewell@xxxxxxxxxxxx B  Tel: +1 434 924 9973
> Web: http://rotunda.upress.virginia.edu/