[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

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

---

---

On Mon, Nov 03 2008 16:07:35 +0000, andrew.j.welch@xxxxxxxxx wrote:
>> 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? :)

Of course.  You'd want a list of what is only matched by built-in or
wildcard templates.

> 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
> change.

What does the IDE show for the one added optional attribute among twenty
added required elements?

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

I'm not saying that you should choose between them either.

Leaving aside the two questions of whether or not schema awareness is
always an option (e.g., when you are using translets) and of exactly how
much automated checking is "fashionable" for XSLT to begin with, neither
schema awareness nor unit testing is a panacea.

Schema awareness type checking is good for saving you from yourself (and
I do make liberal use of 'as="..."' to save me from myself when writing
XSLT 2.0), but you can still go wrong.

Unit tests are only as good as the effort you put into creating them
and, as you note, keeping them up to date.  I recently wrote some test
cases for an extension to a FO processor: the test cases all initially
passed the area tree checks because I hadn't added assertions about the
extension I was testing; they passed again when I added assertions based
on the current output; and they all failed when I changed where the
extra FOs were added to the area tree, even though the PDF output was
visually identical (which I was testing a different way).

Even at its best, unit testing won't catch everything [1] (it won't come
close) any more than type checking will.  A combination of
tests/checks/reviews will catch more than will using one method alone.

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

And if the schema doesn't extend to patterns or enumerations for those
attribute values and your brain short-circuits and you produce:

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

?

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

I'm all for testing it in as many ways as possible for the least effort
and the maximum confidence in the result.  So using schema awareness
when it is an option is perfectly fine by me.

Regards,


Tony Graham                         Tony.Graham@xxxxxxxxxxxxxxxxxxxxxx
Director                                  W3C XSL FO SG Invited Expert
Menteith Consulting Ltd
XML, XSL and XSLT consulting, programming and training
Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
Registered in Ireland - No. 428599   http://www.menteithconsulting.com
  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
xmlroff XSL Formatter                               http://xmlroff.org
xslide Emacs mode                  http://www.menteith.com/wiki/xslide
Unicode: A Primer                               urn:isbn:0-7645-4625-2

[1] https://www.menteithconsulting.com/wiki/XTech2007/MyStylesheetRunsBut#EffectivenessofUnitTesting

---