Re: [xsl] XPath "//", speed, and Saxon

Subject: Re: [xsl] XPath "//", speed, and Saxon
From: "Andrew Welch" <andrew.j.welch@xxxxxxxxx>
Date: Mon, 3 Nov 2008 16:07:35 +0000
> In some ways, the old-fashioned 'match="*"' template rule that emits a
> message or outputs the element name in red for any element that isn't
> handled elsewhere is still useful even when you have schema awareness.

> or a coverage tool (non-existent, AFAIK) that tells you whether your
> stylesheet can handle everything in a schema would also still be useful.

wouldn't the match="*" template kind of skew your coverage checking? :)

The other benefit of schema awareness is when the schema changes, you
just need to modify your transform accordingly (hopefully with lots of
underlining and help from the IDE) and you're ready to go.  With unit
tests, you'd have to go through and update the tests based on that

I'm not saying choose between them (unit tests are ideal for testing
functions) just that for XSLT the "fashionable" way of development
shouldn't be unit tests and coverage tools, it should be schema based.

For example, you have a template which should output:

<foo a="b" b="c"><bar/></foo>

Why go to all the effort of setting up a unit test, along with a
suitable way of comparing the expected and actual fragments, when you
could just add an "as" attribute to the template:

<xsl:template match="whatever" as="element(foo)">

Then if the template changes or the schema changes and that template
generates the wrong output, you get a message, line number etc and if
you're lucky a big red line under that template in the IDE.

Reducing faults through schema-awareness is the best approach and, if
you like, writing input and output schemas really is test-first
development.  You're still comparing expected with actual output, just
in a different way.

Andrew Welch

Current Thread