Ultimately though, for checking the "correctness" of the result of a
transform, I think you just need to execute XPaths against it, which
are more tolerant of subtle changes in the output.  That was the idea
behind xchecker, which then became running xquery and transforms to
overcome the limitations of what xpath can check.

Would you expand on that a little please Andrew?
I can see (initially) that xpath comparisons would
be easier (ws etc), but what made you change to
'running xquery and transforms'?
What was xpath missing?

The idea behind xchecker is that each test returns true() or a
sequence of true()s to pass, and fails if any item is the sequence is
not true(). For example,

So it is convenient to run multiple tests at a single 'call'?
OK, I haven't got that far yet.
I do note you're using something like Schematron ideas,
e.g. simple paras don't have titles.
Are you 'ignoring' text content then? Just comparing
structures... or testing for a particular element present|not  ?

That seems like the poor mans xml diff.
It should be fairly straight forward with xpath alone?
Your additions seem to address test groups rather
than simple tests?

Allowing transforms or xqueries to be just makes it easier to test
what you need (say you need a variable) and construct a better failure
message, and means you can test however you like.. comparing xml if
you really wanted to, or just simple xpaths.

I'm thinking of testing the output of a single template
against an expected 'structure'.

Using a schema aware transform you could add an "as" attribute to the
template which refers to a custom type, or if using a basic processor
just validate the result yourself.

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk