Re: [xmlroff] Re: xmlroff 0.3.1

[Tony G. <Ton...@Su...>]

Peter Saint-Andre <st...@ja...> writes:
> In article <m33...@Su...>, Tony Graham <Ton...@Su...> 
> wrote:
>
>> xmlroff 0.3.1  is now available.  Also new testsuite and testing
>> packages and a new testresults package with the results of running
>> xmlroff 0.3.1 on the testsuite.
>
> Thanks for your work on xmlroff. I discovered it just today and hope to 
> give it a whirl here soon. What help is needed on the project? (Note: I 
> am not a C coder, but could help with testing, XSLTs, etc.)

Thank you for your offer.  It is, of course, gratefully accepted.

On the testing side, there are several thousand tests from NIST and
elsewhere that could be incrementally added to the xmlroff test
results once someone does the initial work of running them once and
checking the result.

On the XSLT side, I have a nagging irritation with the DocBook website
stylesheets that wouldn't take much to fix.

The 'spec-dump' module is all XSLT, but since you're avowedly not a C
coder, it's unlikely that I could interest you in that.

Mixing testing and XSLT, the 'testing' module could do with an
overhaul.  Its current limitations include:

 - It is hardcoded for producing PDF, but it should be possible to
   configure a test setup to produce and meaningfully compare
   PostScript output.

 - It is probably too hardcoded to running the tests from the
   directory containing the 'testing' perl scripts and stylesheets.
   Beyond running tests for both PDF and PostScript output, I need a
   test setup that I can run to compare the current xmlroff version
   against the previous release as well as keeping my current test
   setup that I continually run as I make changes to xmlroff.

 - The current setup to change between static reports and reports with
   forms is beyond clunky.

 - Updating results using the form in an individual report doesn't
   regenerate the individual report.

 - Now that Mozilla, etc. supports XSLT, the reports should be XML
   with styles applied rather than batch-generated HTML.

 - Currently the test results are all recorded in one file that
   conforms to the DTD developed for the XSL 1.0 Candidate
   Recommendation testing.  That is useful if we ever need to exchange
   test result information, but it's unlikely that we will unless
   xmlroff implements any XSL 1.1 features for the XSL 1.1 Candidate
   Recommendation testing phase.  As such, if the individual reports
   become XML, then it would be convenient if the test result
   information stayed in the individual files and the single
   testresults.xml file was just generated if and when required by
   merging the information from the individual XML files.

 - The look of the reports needs work.

The choice is yours.

Regards,


Tony.

p.s. If you're reading the xmlroff-list using gmane, you can configure
     your subscription so you're not also sent list posts as email.