OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [docbook-apps] docbook testing


Stefan Seefeld wrote:

> I think this has to be an incremental process, as even *some* testing is 
> better than no testing. In particular, I can see different steps:
> 
> 1) Run different XSLT processors / configurations on the various 
> stylesheet sets ((X)HTML, FO, man, etc.) and make sure they don't fail.

Is Norms test document appropriate for all these output formats?


> 
> 2) validate the output for syntactical correctness (xmllint without 
> validation for XML output, say)

?? Not possible for FO?
Almost definately not possible for html?
Validate man pages?

Another test candidate though.



> 
> 4) validate final output by visually inspecting it.

-1 for me.
If it can't be automated it won't be run.


> 
> 
> The last step (4) is obviously hardest, and almost impossible to 
> automatize. But even if you only do (1) you already catch those errors 
> that made the 1.74.1 release a failure.

good point.
Anyone know if we can trap transformation errors for all | some | the 
main XSLT engines?




> 
> And *please* make sure the testing procedure you implement is applicable 
> by ordinary people (e.g., doesn't involve commercial tools), as that 
> will increase chances that contributors will run it, too.

No such thing as ordinary people Stefan :-)

Constraints.
1. Configurable (where is ant, where is docbook etc)
2. Easily run. ????? Yuk. IMHO an ant script is easily run.
     Perhaps Tony's suggestion could come into its own here?


+1, from Tony G.
Building Docbook?  I think Norm used to use make to do part of the 
build? Is that still the case? for the schema? for the stylesheets?
How used please?

Keith pointed me to 
https://docbook.svn.sourceforge.net/svnroot/docbook/trunk/xsl/README.BUILD
which seems to clarify. Thanks Keith.
Lots of useful info there.

Note:
0. Third-party build dependencies.
    The following is an incomplete list of some of the third-party
    tools and libraries you need to have installed before building.

    - xsltproc and xmllint
    - egrep and sed
    - Perl and the XML::Path module
    - Java and Apache ant (for building the extension jar files)
  - tar, gzip, bzip2, and zip
    - openssh
    - lftp (for uploads to the Sourceforge FTP site)
    - w3m browser (default) or optionally lynx or elinks
      (for generating the plain-text release notes)
    - dblatex, xep, or fop (for building doc PDFs)


I.e. Perl, XML::modules egrep and sed. Is that expecting too much for
a user on Windows/Mac?

Even setting up Perl can be a nightmare.

build testing left as an issue. Perhaps classifying testing
as level n, n+1, n+2 etc, only the hairy hackers should attempt
n+m?  Anyone can download the test suite and run the tests though?

Some sort of matrix, tools needed vs tests run?








regards

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]