docbook-apps

Hi,

when developing customizations for the DocBook stylesheets I have
always the feeling I forget something important and work without any
"safey net". ;)
As such, it would be great to have a "test framework" which could
automatically check the transformation results with the expected
behaviour.

I know of XSpec from Jeni Tennison which goes in this direction.
However, as far as I know, this is for XSLT 2, not XSLT 1. It's used
for developing and testing the upcoming XSLT 2 DocBook stylesheets.

I'm not sure how easily could this be adapted to our current XSLT 1
base. Are there other (better?) solutions?

How do *you* develop and test your stylesheets? Has anybody used such
frameworks? Any help is greatly appreciated. :)


--
Gruß/Regards,
Thomas Schraitle

On Thu, 16 Oct 2014 10:56:11 +0200
Thomas Schraitle <tom_schr@web.de> wrote:

> Hi,
>
> when developing customizations for the DocBook stylesheets I have
> always the feeling I forget something important and work without any
> "safey net". ;)
> As such, it would be great to have a "test framework" which could
> automatically check the transformation results with the expected
> behaviour.
>
> I know of XSpec from Jeni Tennison which goes in this direction.
> However, as far as I know, this is for XSLT 2, not XSLT 1. It's used
> for developing and testing the upcoming XSLT 2 DocBook stylesheets.
>
> I'm not sure how easily could this be adapted to our current XSLT 1
> base. Are there other (better?) solutions?
>
> How do *you* develop and test your stylesheets? Has anybody used such
> frameworks? Any help is greatly appreciated. :)

xspec is for the general case. Question: Is docbook sufficiently 'firm'
to allow a specific solution? I.e. for any given input at the document
level, we should be able to specify the 'required' / expected output?
That would allow a diff of two files, albeit an XML diff
(deep-equals?) which would make for easier testing of the (x)html
output.
For fo, would the xsl-fo be sufficient? I'd guess so. Hence a similar
solution would be adequate.

Just my 2cents worth.

regards


--

regards

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

Hi Dave,

thanks for your reply! :)

On Thu, 16 Oct 2014 12:25:40 +0100
davep <davep@dpawson.co.uk> wrote:

> [...]
> > How do *you* develop and test your stylesheets? Has anybody used
> > such frameworks? Any help is greatly appreciated. :)
>
> xspec is for the general case. Question: Is docbook sufficiently
> 'firm' to allow a specific solution?

As Norman used XSpec for the DocBook XSLT2 stylesheets, I would say it
is sufficiently "firm". ;)


> I.e. for any given input at the
> document level, we should be able to specify the 'required' /
> expected output? That would allow a diff of two files, albeit an XML
> diff (deep-equals?) which would make for easier testing of the (x)html
> output.
> For fo, would the xsl-fo be sufficient? I'd guess so. Hence a similar
> solution would be adequate.

An XML diff came also to my mind. However, as most XML diffs are
commercial, I wouldn't recommend it as solution in a purely open source
environment. Another reason why I didn't investigate more such power
isn't really necessary.

I think, in most cases we are only interested in answers of the
question "is attribute X there?", "does attribute X has the value Z?",
"is this parent-child relationship correct?", or "does the expected text
show up?" If whitespace doesn't matter (in most cases it won't), the
XML output could be either a) investigated with an XPath expression, or
b) "normalized" and a normal diff applied. I guess it would be a lot
faster than any XML diffs. ;)


Apart from this technical implementations, I'm more interested in the
overall structure. What would be a "good" test environment for
stylesheet customizations? Or even the DocBook stylesheets itself?

It seems to me, the XSLT 1 stylesheets are used a lot and they won't be
replaced soon by the XSLT 2 incarnations. If useful and technical
possible, why not define/recommend/add some "test environment" to help
contributors and developers? :)


--
Gruß/Regards,
Thomas Schraitle

On Thu, 16 Oct 2014 15:11:27 +0200
Thomas Schraitle <tom_schr@web.de> wrote:

> Apart from this technical implementations, I'm more interested in the
> overall structure. What would be a "good" test environment for
> stylesheet customizations? Or even the DocBook stylesheets itself?

Start at the bottom? A basic 1.0 transformer and standard docbook?
I know Norm et al have test files. How about finding a way to check
the actual with expected output (using either XSLT 1 or 2 and 'some
form' of checking). Once you start to build up a series of tests that
is looking promising, then address integration of a test suite?
Perhaps using ant or bash or ..... whatever?
With your (reasonable IMHO) basic Is this there (attribute/element)
then I think this approach quite reasonable and XSLT (Schematron?)
should suffice without buying xml diff tools.

HTH




--

regards

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

On 16.10.2014 10:56, Thomas Schraitle wrote:
> I'm not sure how easily could this be adapted to our current XSLT 1
> base. Are there other (better?) solutions?

If you will not use extensions, it should be possible to run DocBook
XSLT stylesheets in XSLT 2.0 processor, hence use XSpec.

Jirka

--
------------------------------------------------------------------
Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz
------------------------------------------------------------------
Professional XML consulting and training services
DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
------------------------------------------------------------------
Bringing you XML Prague conference http://xmlprague.cz
------------------------------------------------------------------

Hi,

sorry for the delay.

On Thu, 16 Oct 2014 16:04:53 +0200
Jirka Kosek <jirka@kosek.cz> wrote:

> On 16.10.2014 10:56, Thomas Schraitle wrote:
> > I'm not sure how easily could this be adapted to our current XSLT 1
> > base. Are there other (better?) solutions?
>
> If you will not use extensions, it should be possible to run DocBook
> XSLT stylesheets in XSLT 2.0 processor, hence use XSpec.

Yes, I've tried it and most of the time it works. :)

Unfortunately, if you really depend on extension functions (like the
omnipresent exsl:node-set()) you can't avoid it.

Have anybody tried a different approach? Python? Ruby? Something else?


Thanks anyway!

--
Gruß/Regards,
Thomas Schraitle

On Thu, October 16, 2014 9:56 am, Thomas Schraitle wrote:
> when developing customizations for the DocBook stylesheets I have
> always the feeling I forget something important and work without any
> "safey net". ;)
> As such, it would be great to have a "test framework" which could
> automatically check the transformation results with the expected
> behaviour.
>
> I know of XSpec from Jeni Tennison which goes in this direction.
> However, as far as I know, this is for XSLT 2, not XSLT 1. It's used
> for developing and testing the upcoming XSLT 2 DocBook stylesheets.
>
> I'm not sure how easily could this be adapted to our current XSLT 1
> base. Are there other (better?) solutions?

I have a page about testing XSLT at
http://menteithconsulting.com/wiki/TestingXSLT that lists several XSLT 1.0
frameworks.

However, as Jirka said, running XSpec on your customisation won't be any
different from running a XSLT 2.0 processor directly.

> How do *you* develop and test your stylesheets? Has anybody used such
> frameworks? Any help is greatly appreciated. :)

For XSLT, I mostly use XSpec (though I still like the model of Juxy).

With XSpec, you can use whole documents as input to a test or make a
minimal context as part of the XSpec test itself.

You could probably write XSpec tests for custom templates easily enough,
but if you're setting parameters that have effect all through your output,
it would be harder to make assertions about the result.

Where the documents are complex and the stylesheets can change a lot,
tests can go out-of-date quickly, so there I tend to implement being able
to take snapshots of the output and being able to compare the current
output against a previous snapshot to see what's changed.

If you're producing XSL-FO output, you can use the open-source xmlroff
testing module or Antenna House's AHRTS to produce a report of the visual
difference between the current formatted output and a reference result.

Regards,


Tony Graham tgraham@mentea.net
Consultant http://www.mentea.net
Chair, Print and Page Layout Community Group @ W3C XML Guild member
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Mentea XML, XSL-FO and XSLT consulting, training and programming