Thread: [Refdb-users] User feedback 3
Status: Beta
                
                Brought to you by:
                
                    mhoenicka
                    
                
            | 
      
      
      From: David N. <dav...@bi...> - 2004-02-29 13:21:23
       | 
| [.. continued] 6. If refdbxml is edited to set saxon as default processor, the make procedure fails. The problem occurs with file docbk-refdblib.xsl. Here is the output: $ make html refdbxp -t db31x < basic-doc.short.xml > basic-doc.xml runbib -d refs_computing -S Eur.J.Pharmacol. -t db31x basic-doc.xml 5 reference(s) formatted, 0 failed refdbxml -s Eur.J.Pharmacol.html.xsl -t html basic-doc.xml Error at xsl:with-param on line 74 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-html/docbk-refdb-html.xsl: Variable ADVSTURLSTYLE has not been declared Error at xsl:choose on line 1826 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: Element must only be used within a template body Error at xsl:with-param on line 1828 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1831 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1834 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1837 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1840 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1843 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1846 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1849 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1852 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1855 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1858 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1861 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1864 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1867 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1870 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1873 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1876 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1879 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1882 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1885 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1888 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1891 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1894 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1897 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1900 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1903 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1906 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1909 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1912 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1915 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1918 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1921 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1924 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1927 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Error at xsl:with-param on line 1930 of file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl: xsl:with-param cannot appear as a child of xsl:when Transformation failed: Failed to compile stylesheet. 37 errors detected. My powers of XSL-fu are weak, so I cannot say why this this occurring with saxon and not with xsltproc. Is saxon being too picky? It is a problem, however, as it is occurring with one of the major xsl processors. This was a large problem for me because I initially set refdbxml to use saxon (it was my default parser until refdb) and had no end of problems. 7. Staying with saxon, if it is ever able to work with refdb, it would be good to have an option to run it with the xerces parser. This requires a (lengthy) command line option, but it should be rather doable. I have found that using xerces with saxon results in much better processing of some entities such as quotes and n/mdashes, especially in html output. [To be continued...] Regards, David. | 
| 
      
      
      From: Markus H. <mar...@mh...> - 2004-03-01 22:40:22
       | 
| David Nebauer writes: > [.. continued] > > 6. If refdbxml is edited to set saxon as default processor, the make > procedure fails. > > The problem occurs with file docbk-refdblib.xsl. Here is the output: > > $ make html > refdbxp -t db31x < basic-doc.short.xml > basic-doc.xml > runbib -d refs_computing -S Eur.J.Pharmacol. -t db31x basic-doc.xml > 5 reference(s) formatted, 0 failed > > refdbxml -s Eur.J.Pharmacol.html.xsl -t html basic-doc.xml > Error at xsl:with-param on line 74 of > file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-html/docbk-refdb-html.xsl: > Variable ADVSTURLSTYLE has not been declared This is a typo in docbk-refdb-html.xsl. Change this to ADVSURLSTYLE (without the 'T' after ADVS). I'm not an XSLT guru but fixing this might fix the other error messages as well. This does not exactly explain why xsltproc does not complain, though. I've fixed this in CVS anyway. > > 7. Staying with saxon, if it is ever able to work with refdb, it would > be good to have an option to run it with the xerces parser. This > requires a (lengthy) command line option, but it should be rather doable. > I'm reluctant to fiddle with this stuff as the Java installations are even more diverse in terms of install directories between systems than standard C/C++ programs are. A simple configure test can verify the installation of xsltproc, but not of saxon and other Java tools (at least I haven't seen a configure script that I could steal code from). If you think there is a generally applicable way to handle this, please let me know. I'll be happy to include this feature. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de | 
| 
      
      
      From: David N. <dav...@bi...> - 2004-03-02 08:06:40
       | 
| Hi Markus,
> > refdbxml -s Eur.J.Pharmacol.html.xsl -t html basic-doc.xml
> > Error at xsl:with-param on line 74 of 
> > file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-html/docbk-refdb-html.xsl:
> >   Variable ADVSTURLSTYLE has not been declared
>
>This is a typo in docbk-refdb-html.xsl. Change this to ADVSURLSTYLE
>(without the 'T' after ADVS). I'm not an XSLT guru but fixing this
>might fix the other error messages as well. This does not exactly
>explain why xsltproc does not complain, though. I've fixed this in CVS
>anyway.
>  
>
I'm afraid it does not fix the following messages.  Here is the current 
error output:
$ make html
refdbxp -t db31x < basic-doc.short.xml > basic-doc.xml
runbib -d refs_computing -S Eur.J.Pharmacol. -t db31x basic-doc.xml
5 reference(s) formatted, 0 failed
refdbxml -s Eur.J.Pharmacol.html.xsl -t html basic-doc.xml
Error at xsl:choose on line 1826 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  Element must only be used within a template body
Error at xsl:with-param on line 1828 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1831 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1834 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1837 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1840 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1843 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1846 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1849 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1852 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1855 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1858 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1861 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1864 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1867 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1870 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1873 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1876 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1879 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1882 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1885 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1888 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1891 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1894 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1897 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1900 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1903 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1906 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1909 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1912 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1915 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1918 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1921 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1924 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1927 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Error at xsl:with-param on line 1930 of 
file:/usr/local/share/refdb/xsl/docbk-refdb-xsl/docbk-lib/docbk-refdblib.xsl:
  xsl:with-param cannot appear as a child of xsl:when
Transformation failed: Failed to compile stylesheet. 36 errors detected.
The situations it reports are accurate.  The template starting at line 
1821 _is_ the only template where <xsl:choose> appears in a different 
location to all the others.  It also appears to be the only template 
where xsl:withparam _is_ a direct child of xsl:when.
A representative snippet of the "non-erroring" templates:
<xsl:template match="bibliomset[@relation='seditor']" mode="refdb">
  <xsl:variable name="reftype" select="ancestor::bibliomixed/@role"/>
      <xsl:choose>                        <--- **
        <xsl:when test="$reftype='ABST'">
          <xsl:call-template name="refdb-process-inline">      <--**
            <xsl:with-param name="style" select="$ABSTSEDITORLISTSTYLE"/>
          </xsl:call-template>
        </xsl:when>
The "erroring" template:
  <xsl:template match="ulink" mode="refdb">
    <xsl:variable name="reftype" select="ancestor::bibliomixed/@role"/>
      <xsl:variable name="target" select="@url"/>
      <a href='#{$target}'>
      <xsl:call-template name="refdb-literal">
        <xsl:choose>                            <--**
          <xsl:when test="$reftype='ABST'">
            <xsl:with-param name="style" select="$ABSTURLSTYLE"/>     <--**
          </xsl:when>
What Saxon is saying about this part of the stylesheet is certainly 
true.  I don't know enough about xsl to know whether this stylesheet is 
strictly legal.  If this xsl is strictly legal and Saxon is mistakenly 
choking on it, then I'll need to raise this issue on the Saxon forums.  
It is, however, possible that Saxon is picking up malformed xsl that 
xsltproc is happy to live with.  In that case, this stylesheet needs to 
be corrected.
Without knowing anything about xsl, I attempted to use xslint to check 
the offending stylesheet.  It output a vast number of cryptic error 
messages and I quickly abandoned that line of inquiry.  Of course, I may 
have invoked it incorrectly or something.  It will require someone with 
more xsl knowledge than I currently possess to decide on this 
styleheet's correctness.
Regards,
David.
 | 
| 
      
      
      From: Markus H. <mar...@mh...> - 2004-03-03 23:27:07
       | 
| David Nebauer writes: > The situations it reports are accurate. The template starting at line > 1821 _is_ the only template where <xsl:choose> appears in a different > location to all the others. It also appears to be the only template > where xsl:withparam _is_ a direct child of xsl:when. > [...] > What Saxon is saying about this part of the stylesheet is certainly > true. I don't know enough about xsl to know whether this stylesheet is > strictly legal. If this xsl is strictly legal and Saxon is mistakenly > choking on it, then I'll need to raise this issue on the Saxon forums. > It is, however, possible that Saxon is picking up malformed xsl that > xsltproc is happy to live with. In that case, this stylesheet needs to > be corrected. > Your analysis is correct. I've investigated this and found out that the .xsl file represents the status of some unfinished hacking. I've updated the Perl script that generates the .xsl file and hope that the generated file works for Saxon as well. I've sent you an updated version by private mail. Please let me know whether or not it works. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de | 
| 
      
      
      From: David N. <dav...@bi...> - 2004-03-02 08:58:05
       | 
| Hi Markus,
> > 7. Staying with saxon, if it is ever able to work with refdb, it would 
> > be good to have an option to run it with the xerces parser.  This 
> > requires a (lengthy) command line option, but it should be rather doable.
> > 
>
>I'm reluctant to fiddle with this stuff as the Java installations are
>even more diverse in terms of install directories between systems than
>standard C/C++ programs are. A simple configure test can verify the
>installation of xsltproc, but not of saxon and other Java tools (at
>least I haven't seen a configure script that I could steal code
>from). If you think there is a generally applicable way to handle
>this, please let me know. I'll be happy to include this feature.
>  
>
Providing the class path has been set up correctly in each case, the 
command to invoke the Saxon processor with or without the Xerces parser 
is the same regardless of the installation configuration of Saxon or 
Xerces -- this is part of the promise of Java, after all ;-)
Here is the command to invoke vanilla Saxon (I'm cribbing from Bob 
Stayton's book again) for html output:
java  -cp $CLASSPATH \
    com.icl.saxon.StyleSheet  \
    -o myfile.html  \
    myfile.xml  \
    docbook-xsl/html/docbook.xsl
Here is the same command, but specifying use of the Xerces parser:
java -cp $CLASSPATH \ 
  -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl \
  -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl \
  com.icl.saxon.StyleSheet  \
  -o myfile.html  \
  myfile.xml  \
  docbook-xsl/html/docbook.xsl
At first glance it looks hideous, but there are simply two additional 
command line options specifying the parser, with the rest being the same.
I don't know if it's necessary to worry about java-based apps like 
Xalan, Saxon, Xerces or FOP at configure time.  You can keep xsltproc as 
the default and, as you do now, make it clear in the manual that use of 
Saxon and Xalan require a working stallation of these packages.
At this point may I make a bold suggestion: the addition to refdb of a 
refdbxml configuration/init file, presumably .refdbxmlrc.  This would 
have the following advantages:
1. Rather than directly editing refdbxml, as is necessary now if you 
want to changes xslt processors, you can instead nominate the processor 
to use in the config file.  This makes your choices upgrade-proof.  You 
could either have saxon and saxon-xerces as choices for the processor, 
or you could have a separate variable (use-xerces) in the init file.
2. If you add support for FOP, there needs to be a way to nominate which 
FO processor to use.  An init file makes this easy.
3. I would dearly love to see it possible to nominate, in this init 
file, a classpath specific to each java application.  Perhaps the use of 
variables such as: saxon-classpath, xalan-classpath, xerces-classpath 
and fop-classpath.  These classpaths could be extracted by refdbxml and 
used as a -cp command-line option when invoking the relevant processor.
My thinking here is that, with 4 java-based apps in potential use 
(saxon, xalan, xerces and fop) the current "common classpath" stands to 
become increasingly complex.  Relying on a single classpath variable for 
increasing numbers of java applications is difficult to debug, difficult 
to maintain, unwieldy, inelegant and just plain _messy_ .
I realise you can nominate the desired processor on the command line 
when invoking refdbxml, but using the init file approach I have 
suggested would be consistent with the refdbnd/"make" approach, which 
relies heavily on config files.  (And I just _love_ refdbnd and the 
makefile approach).
My powers of shellscript-fu are a little stronger than my (pathetic) 
xsl-fu, and I could try to knock up a "proof-of-concept" if you are 
inclined to look into my suggestion.
Regards,
David.
 | 
| 
      
      
      From: Markus H. <mar...@mh...> - 2004-03-03 23:27:15
       | 
| David Nebauer writes: > At this point may I make a bold suggestion: the addition to refdb of a > refdbxml configuration/init file, presumably .refdbxmlrc. This would > have the following advantages: > > 1. Rather than directly editing refdbxml, as is necessary now if you > want to changes xslt processors, you can instead nominate the processor > to use in the config file. This makes your choices upgrade-proof. You > could either have saxon and saxon-xerces as choices for the processor, > or you could have a separate variable (use-xerces) in the init file. > > 2. If you add support for FOP, there needs to be a way to nominate which > FO processor to use. An init file makes this easy. > > 3. I would dearly love to see it possible to nominate, in this init > file, a classpath specific to each java application. Perhaps the use of > variables such as: saxon-classpath, xalan-classpath, xerces-classpath > and fop-classpath. These classpaths could be extracted by refdbxml and > used as a -cp command-line option when invoking the relevant processor. > > My thinking here is that, with 4 java-based apps in potential use > (saxon, xalan, xerces and fop) the current "common classpath" stands to > become increasingly complex. Relying on a single classpath variable for > increasing numbers of java applications is difficult to debug, difficult > to maintain, unwieldy, inelegant and just plain _messy_ . > This is my favourite rant about Java ;-) > > My powers of shellscript-fu are a little stronger than my (pathetic) > xsl-fu, and I could try to knock up a "proof-of-concept" if you are > inclined to look into my suggestion. > I strongly encourage you to whip up a proof of concept. The shell magic to read config files is not that hard BTW, the db2ris script shows an example how to do this. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de | 
| 
      
      
      From: David N. <dav...@bi...> - 2004-03-04 15:04:59
       | 
| Hi Markus,
>David Nebauer writes:
> > At this point may I make a bold suggestion: the addition to refdb of a 
> > refdbxml configuration/init file, presumably .refdbxmlrc.  This would 
> > have the following advantages:
>  
>
<snip>
>I strongly encourage you to whip up a proof of concept. The shell
>magic to read config files is not that hard BTW, the db2ris script
>shows an example how to do this.
>
At the end of this message please find:
1. An init file for refdbxml: refdbxmlrc
2. A re-written refdbxml to use the init file
I had these goals in mind when re-writing refdbxml:
1. Ability to specify in init file which XSLT processor to use.
2. Add to saxon support for xerces xml parser and the apache resolver.
3. Ability to use additional FO processors (fop and xep) and specify in 
init file which one to use.
4. Ability to declare classpaths for java-based processors in init file 
-- with a different classpath for XSLT and FO processors.
First, some notes about the new files:
- I've added an extra command line parameter to refdbxml: -f   -- the fo 
processor
- kept boilerplate code from db2ris about looking for global config file 
(eg. /etc/refdb/refdbxmlrc)
    - if you decide to keep this, you'll need to adjust the 
configuration install step to insert $globalconfig as per db2ris
- I've added 'saxon-xerces' as an XSLT processor option: it uses the 
xerces xml parser instead of the inbuilt Aelfred parser (everybody does 
this, and all the experts recommend it)
- I've added to both saxon and saxon-xerces command lines the options 
for catalog resolution
- until now passivetex has been the only fo processor -> I've added fop 
and xep.  There's a new function called 'process_print' which handles 
the conversion from fo to printable output (rtf|pdf)
    - there's a possibility someone could invoke refdbxml with a pdf fo 
processor (like passivetex or fop) but specify rtf output.  I'm not sure 
what would happen then, but I don't think it would be pretty
    - there's a nasty hack regarding xep -- see notes in refdbxml 
regarding it
-  not sure what happens if someone puts a space in their classpath
- original default classpath from refdbxml is still there and is used if 
none specified in init file.
Results of testing (via 'make'):
- tested with no init file --> WORKED
- tested with init file present but all options commented out --> WORKED
- tested with XSLT processor xsltproc --> WORKED
- tested with XSLT processor saxon --> WORKED
- tested with XSLT processor saxon-xerces --> WORKED
- tested with FO processor passivetex --> WORKED
- tested with FO processor fop --> WORKED
- tested with FO processor xep --> WORKED (albeit with nasty hack)
I haven't tested it with jfor, xt or xalan, but the commands are 
identical to those present in the original refdbxml, so they should work.
All comments, especially (constructive) criticism welcomed.
Regards,
David.
refdbxmlrc:
...........................................................................................................
# This is an example configuration file for refdbxml, the XML transformation
# tool of RefDB
# RefDB is a reference database and bibliography tool, see
# http://refdb.sourceforge.net for further information
# Syntax rules of this file:
# 1. Each line contains a pair of variable name and variable value,
#    separated by whitespace.
# 2. The hash (#) denotes the start of a comment, the rest of the line
#    will be ignored
# 3. The line ending must be Unix-style (LF) regardless of the operating
#    system
# Note: Each of these options can be overridden at execution time by
# invoking refdbxml with command line options.
# To see the available options, type 'refdbxml -h' or refer to the manual.
## XSLT processor.
# An xslt processor is used to transform your DocBook xml document to
# (x)html or fo.
# Currently available choices are:
#   xalan
#   xt
#   xsltproc (default)
#   saxon
#   saxon-xerces
# Note: 'saxon-xerces' refers to the saxon xslt processor using the
# xerces xml parser from Apache.
# Note: 'saxon', both with and without 'xerces', will use the Apache 
resolver.
# Note: _You_ must ensure that the xslt processor is installed and
# correctly configured.  RefDB does not check.
#xslt_processor    xsltproc
## XSLT classpath
# You only need to set this variable if your XSLT processor is java-based.
# If it's not java-based (eg. xsltproc), don't set this variable.
# Some XSLT processors _are_ java-based (including xalan, xt and saxon)
# and need to access certain directories and java class files.
# This is done by specifying a classpath.
# Refer to the application's documentation for further information
# about the necessary classpath.
# One approach is to choose a directory and put in it symlinks to
# the required jars, so the classpath may be something like:
#   /usr/share/java
# Do not use backslashes to concatenate lines.
#xslt_classpath    /usr/share/java
## FO processor
# When producing printed output the xslt processor produces a "formatted
# objects" file (.fo).  An FO processor then transforms this to printed
# output.
# Currently available choices are:
#   passivetex (default) -> pdf output
#   fop                  -> pdf output
#   xep                  -> pdf output
#   jfor                 -> rtf output
# Note: _You_ must ensure that the xslt processor is installed and
# correctly configured.  RefDB does not check.
#fo_processor    passivetex
## FO classpath
# You only need to set this variable if your FO processor is java-based.
# If it's not java-based (eg. passivetex), don't set this variable.
# Some FO processors _are_ java-based (including fop, xep and jfor)
# and need to access certain directories and java class files.
# This is done by specifying a classpath.
# Refer to the application's documentation for further information
# about the necessary classpath.
# One approach is to choose a directory and put in it symlinks to
# the required jars, so the classpath may be something like:
#   /usr/share/java
# Do not use backslashes to concatenate lines.
#fo_classpath    /usr/share/java
## Include following variables to cover all command line options
## Not needed with refdbnd/make system
## stylesheet
# refdbxml currently sets no stylesheet default, relying on command line
# option.  I'll do the same.
#stylesheet       
## output format
# The format of the output file.
# Current options are:
#   html (default)
#   pdf
#   rtf
# refdbxml currently sets outformat to html as default. I'll do the same.
#outformat    html
...........................................................................................................
refdbxml:
...........................................................................................................
#!/bin/bash
# refdbxml - creates formatted output from XML documents
# Markus Hoenicka <ma...@xx...> 2001-10-10
# $Id: refdbxml.in,v 1.9 2003/12/21 22:58:22 mhoenicka Exp $
# OPTIONS: -s (stylesheet) -h (invoke help), -p (processor), -t (output 
format)
## added extra option: -f (fo processor)
# relies on these external programs: SUN JRE, tex, passivetex, xmltex, JFOR
# at least one of: xerces/xalan, xp/xt, xsltproc, saxon
# and at least one of: passivetex, fop, xep
# no longer a user-customizable section in this file
# -> use config file instead
## initialise variables
# location of the stock DocBook and TEI XSL stylesheets
htmldb="/home/david/data/conf/refdb/xsl/html/docbook.xsl"
xhtmldb="/home/david/data/conf/refdb/xsl/xhtml/docbook.xsl"
fodb="/home/david/data/conf/refdb/xsl/fo/docbook.xsl"
htmltei="/teixsl-html/teihtml.xsl"
xhtmltei="/teixsl-html/teihtml.xsl"
fotei="/teixsl-fo/tei.xsl"
# the default xslt processor: xalan, xt, saxon, saxon-xerces or xsltproc
xslt_processor="xsltproc"
# the default fo processor: passivetex, fop or xep
fo_processor="passivetex"
# the path to the Java class repository. This assumes that all necessary 
.jar
# files are in this directory. If this is not the case, adding a few 
symlinks
# might be the simplest solution
classpath_root="/usr/share/java"
xslt_classpath=""
fo_classpath=""
# some defaults
stylesheet=""
outformat="html"
# determine configuration files
if [ ! -r "$globalconfig" ] && [ -n "$REFDBLIB" ]; then
    globalconfig=$REFDBLIB/refdbxmlrc
fi
userconfig=$HOME/.refdbxmlrc
if [ -n "$globalconfig" ] && [ -r "$globalconfig" ]; then
    allconfigs=$globalconfig
fi
if [ -r "$userconfig" ]; then
    allconfigs=$allconfigs" "$userconfig
fi
# read the settings in the configure file(s)
for config in $allconfigs; do
    while read refdbvar refdbval; do
    if [ -n "$refdbvar" ]; then
        if [ $refdbvar = xslt_processor ]; then
        xslt_processor=$refdbval
        fi
        if [ $refdbvar = xslt_classpath ]; then
        xslt_classpath=$refdbval
        fi
        if [ $refdbvar = fo_processor ]; then
        fo_processor=$refdbval
        fi
        if [ $refdbvar = fo_classpath ]; then
        fo_classpath=$refdbval
        fi
        if [ $refdbvar = stylesheet ]; then
        stylesheet=$refdbval
        fi
        if [ $refdbvar = outformat ]; then
        outformat=$refdbval
        fi
    fi
    done < $config
done
# set processor launch commands for functions which follow
# more maintainable (and less ugly -- check out saxon-xerces!)
# note: saxon|saxon-xerces habe command-line options for catalog resolving
case $xslt_processor in
    xalan    ) xslt_launch="org.apache.xalan.xslt.Process";;
    xt       ) xslt_launch="com.jclark.xsl.sax.Driver";;
    saxon    ) xslt_launch="com.icl.saxon.StyleSheet -x 
org.apache.xml.resolver.tools.ResolvingXMLReader -y 
org.apache.xml.resolver.tools.ResolvingXMLReader -r 
org.apache.xml.resolver.tools.CatalogResolver -u";;
    saxon-xerces ) 
xslt_launch="-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl 
-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl 
com.icl.saxon.StyleSheet -x 
org.apache.xml.resolver.tools.ResolvingXMLReader -y 
org.apache.xml.resolver.tools.ResolvingXMLReader -r 
org.apache.xml.resolver.tools.CatalogResolver -u";;
    xsltproc ) xslt_launch="xsltproc --catalogs --xinclude";;
esac
   
## function definitions
# creates fo output from xml. Arguments: input_filename out_filename
process_fo () {
    case $xslt_processor in
    xalan    ) java -cp "$xslt_classpath" ${xslt_launch} $1 -xsl 
$jfosheet -out $2;;
    xt       ) java -cp "$xslt_classpath" ${xslt_launch} $1 $jfosheet > $2;;
    saxon    ) java -cp "$xslt_classpath" ${xslt_launch} -o $2 $1 
$jfosheet;;
    saxon-xerces ) java -cp "$xslt_classpath" ${xslt_launch} -o $2 $1 
$jfosheet;;
    xsltproc ) ${xslt_launch} $fosheet $1 > $2;;
    esac
}
# creates html output from xml. Arguments: input_filename out_filename
process_html () {
    case $xslt_processor in
    xalan    ) java -cp "$xslt_classpath" ${xslt_launch} -in $1 -xsl 
$jhtmlsheet -out $2;;
    xt       ) java -cp "$xslt_classpath" ${xslt_launch} $1 $jhtmlsheet 
 > $2;;
    saxon    ) java -cp "$xslt_classpath" ${xslt_launch} -o $2 $1 
$jhtmlsheet;;
    saxon-xerces ) java -cp "$xslt_classpath" ${xslt_launch} -o $2 $1 
$jhtmlsheet;;
    xsltproc ) ${xslt_launch} $htmlsheet $1 > $2;;
    esac
}
# creates xhtml output from xml. Arguments: input_filename out_filename
process_xhtml () {
    case $xslt_processor in
    xalan    ) java -cp "$xslt_classpath" ${xslt_launch} -in $1 -xsl 
$jxhtmlsheet -out $2;;
    xt       ) java -cp "$xslt_classpath" ${xslt_launch} $1 $jxhtmlsheet 
 > $2;;
    saxon    ) java -cp "$xslt_classpath" ${xslt_launch} -o $2 $1 
$jxhtmlsheet;;
    saxon-xerces ) java -cp "$xslt_classpath" ${xslt_launch} -o $2 $1 
$jxhtmlsheet;;
    xsltproc ) ${xslt_launch} $xhtmlsheet $1 > $2;;
    esac
}
# creates printable output (pdf|rtf) from fo.
# Arguments: input_filename out_filename
process_print () {
    case $fo_processor in
    jfor )
        java -cp "$classpath" ch.codeconsult.jfor.main.CmdLineConverter 
$1 $2;;
    passivetex )
        if [ ! -e $basename.aux ]; then
            touch $basename.aux
        fi
        cp $basename.aux $basename.aux.$$
        pdfxmltex $basename.fo
        if [ $? -ne 0 ]; then
          exit 1
        fi
        # the following loop should be fixed to run not more
        # than a fixed number of iterations.
        until diff --brief $basename.aux $basename.aux.$$; do
          cp $basename.aux $basename.aux.$$
          pdfxmltex $basename.fo
        done
        rm $basename.aux.$$;;
    fop )
        java -cp "$fo_classpath" org.apache.fop.apps.Fop -fo $1 -pdf $2;;
    xep )
        # Note the ugly hack (actually a cheat) in the xep command:
        # in my evaluation version xep needs to be run from the install
        # directory so it can check the license file. If run from any
        # other location it needs the -DROOT option set to that
        # install directory. Anybody know a way around this?
        java -cp "$fo_classpath" com.renderx.xep.XSLDriver 
-DROOT=/home/david/progs/apps/xep -fo $1 -pdf $2;;
    esac
}
# read the command line options
while getopts ":hp:f:s:t:" opt; do
  case $opt in
    h  ) echo "creates formatted output from a DocBook or TEI XML sources"
     echo 'usage: refdbxml [-h] [-p xslt_processor] [-f fo_processor ] 
[-s stylesheet] [-t outformat] file1 [file2...]'
     echo "Options: -h print this help and exit"
     echo "         -p specify xslt processor: xalan, xt, saxon, or 
xsltproc"
     echo "         -f specify fo processor: passivetex, fop or xep"
     echo "         -s stylesheet (the RefDB-generated driver file)"
     echo "         -t select the output format. Possible values are 
html, xhtml, rtf, pdf."
     exit 0 ;;
    p  ) xslt_processor=$OPTARG;;
    f  ) fo_processor=$OPTARG;;
    s  ) stylesheet=$OPTARG;;
    t  ) outformat=$OPTARG;;
    \? ) echo 'usage: refdbxml [-h] [-p xslt_processor] [-f 
fo_processor] [-s stylesheet] [-t outformat] file1 [file2...]'
     echo 'type refdbxml -h to invoke help'
     exit 1;;
  esac
done
# correct the index so the filename argument is always $1
shift $(($OPTIND - 1))
# test for valid arguments
if [ ! $outformat = html ] && [ ! $outformat = rtf ] && [ ! $outformat = 
pdf ] && [ ! $outformat = xhtml ]; then
  echo "specify one of 'html', 'xhtml', 'rtf', 'pdf' with the -t option"
  exit 1
fi
# pick stylesheet; the values "db" and "tei" use the stock stylesheets
# without any RefDB extensions. To format a document using RefDB 
bibliographies
# the RefDB-generated driver file must be specified here
case $stylesheet in
  db  ) htmlsheet=$htmldb
    xhtmlsheet=$xhtmldb
    fosheet=$fodb;;
  tei ) htmlsheet=$htmltei
    xhtmlsheet=$xhtmltei
    fosheet=$fotei;;
  *   ) if [ $outformat = "html" ]; then
        htmlsheet=$stylesheet
    elif [ $outformat = "xhtml" ]; then
        xhtmlsheet=$stylesheet
    else
        fosheet=$stylesheet
    fi;;
  \? ) echo 'type refdbxml -h to invoke help'
       exit 1;;
esac
# test for valid xslt processor
if [ ! $xslt_processor = "xalan" ] && [ ! $xslt_processor = "xt" ] && [ 
! $xslt_processor = "xsltproc" ] && [ ! $xslt_processor = "saxon" ] && [ 
! $xslt_processor = "saxon-xerces" ]; then
  echo "specify one of 'xalan', 'xt', 'saxon', 'saxon-xerces', 
'xsltproc' with the -p option"
  exit 1;
fi
# test for valid fo processor
# if none specified will be default (passivetex), which is legal
if [ ! $fo_processor = "passivetex" ] && [ ! $fo_processor = "fop" ] && 
[ ! $fo_processor = "xep" ]; then
  echo "specify one of 'passivetex', 'fop', 'xep' with the -f option"
  exit 1;
fi
# on Win32-cygwin, the native Win32 tools want the DOS path
# the variables $jfosheet and jhtmlsheet will receive the appropriate paths
if [ $OSTYPE = "cygwin" ]; then
    # get the full dos path of the classpath root
    osclasspath_root=$(cygpath -w $classpath_root)
    
classpath="$osclasspath_root\avalon-framework-4.0.jar;$osclasspath_root\batik.jar;$osclasspath_root\fop.jar;$osclasspath_root\jfor-0.5.1.jar;$osclasspath_root\jimi-1.0.jar;$osclasspath_root\logkit-1.0b4.jar;$osclasspath_root\sax.jar;$osclasspath_root\xalan.jar;$osclasspath_root\xerces.jar;$osclasspath_root\xp.jar;$osclasspath_root\xt.jar"
    jfosheet=$(cygpath -w $fosheet)
    jhtmlsheet=$(cygpath -w $htmlsheet)
    jxhtmlsheet=$(cygpath -w $xhtmlsheet)
else
    
classpath="$classpath_root/avalon-framework-4.0.jar:$classpath_root/batik.jar:$classpath_root/fop.jar:$classpath_root/jfor-0.5.1.jar:$classpath_root/jimi-1.0.jar:$classpath_root/logkit-1.0b4.jar:$classpath_root/sax.jar:$classpath_root/saxon.jar:$classpath_root/saxon-fop.jar:$classpath_root/saxon-jdom.jar:$classpath_root/xalan.jar:$classpath_root/xerces.jar:$classpath_root/xp.jar:$classpath_root/xt.jar"
    jfosheet=$fosheet
    jhtmlsheet=$htmlsheet
    jxhtmlsheet=$xhtmlsheet
fi
# Set classpath variables to default if not already specified
if ! [ -n "$xslt_processor" ]; then
    xslt_processor=$classpath
fi
if ! [ -n "$fo_processor" ]; then
    fo_processor=$classpath
fi
# loop over all files on the command line
for filename in $*; do
    if [ $OSTYPE = "cygwin" ]; then
      # get the full dos path of the file
      mypath=$(cygpath -w $filename)
    else
      mypath=$filename
    fi
    # extract the basename from the argument
    basename=${mypath%.*}
    case $outformat in
    rtf )
        process_fo $mypath $basename.fo
        if [ $? -ne 0 ]; then
          exit 1
        fi
        process_print $basename.fo $basename.rtf;;
    html)
        process_html $mypath $basename.html;;
    xhtml)
        process_xhtml $mypath $basename.xhtml;;
    pdf )
        process_fo $mypath $basename.fo
        if [ $? -ne 0 ]; then
          exit 1
        fi
        process_print $basename.fo $basename.pdf;;
    esac
done
exit 0
...........................................................................................................
Regards,
David.
 | 
| 
      
      
      From: Markus H. <mar...@mh...> - 2004-03-05 00:37:36
       | 
| Hi David, David Nebauer writes: > At the end of this message please find: > 1. An init file for refdbxml: refdbxmlrc > 2. A re-written refdbxml to use the init file > Thanks for that. I've added refdbxmlrc with some cosmetic changes to CVS. I've also integrated your refdbxml changes into the official version which also required some Makefile.am and configure.in hacking. I've fixed a few obvious typos in the file you sent and made some minor changes, like parametrizing the xep root variable. I've tested the updated script with xsltproc and FOP. I'm currently updating my xerces and Saxon installations, but I expect this will work too. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de | 
| 
      
      
      From: David N. <dav...@bi...> - 2004-03-05 12:28:51
       | 
| Hi Markus,
>Hi David,
>
>David Nebauer writes:
> > At the end of this message please find:
> > 1. An init file for refdbxml: refdbxmlrc
> > 2. A re-written refdbxml to use the init file
> > 
>
>Thanks for that. I've added refdbxmlrc with some cosmetic changes to
>CVS. I've also integrated your refdbxml changes into the official
>version which also required some Makefile.am and configure.in
>hacking. I've fixed a few obvious typos in the file you sent and made
>some minor changes, like parametrizing the xep root variable. I've
>tested the updated script with xsltproc and FOP. I'm currently
>updating my xerces and Saxon installations, but I expect this will
>work too.
>  
>
I've now tested the Makefile against my new refdbxml and refdbxmlrc 
files using all the xslt and fo processors included to date.
This includes: xalan, xt, saxon, saxon-xerces, xsltproc, passivetex, 
fop, xep and jfor.
In every case (except jfor), the Makefile produced the desired output 
without error.
In another post I've mentioned the problem with jfor, which has to do 
with DocBook rather than refdb.
The only thing still bugging me is the theoretical possibility of 
invoking refdbxml with a mismatch between the fo processor and output 
type (eg. jfor processor with pdf output).  Something like the following 
code could be inserted at the start of process_print:
........................................................................
rtf_generators="jfor"
pdf_generators="fop xep passivetex"
case $outformat in
    rtf ) generators=$rtf_generators;;
    pdf ) generators=$pdf_generators;;
esac
processor_outformat_match=false
for generator in $generators ; do
    [ "$generator" = "$fo_processor" ] && processor_outformat_match=true
done
if [ ${processor_outformat_match} = false ] ; then
    echo "Specified FO processor: $fo_processor."
    echo "Specified output format: $outformat."
    echo "Error: $fo_processor does not produce $outformat output."
    exit 1
fi
........................................................................
The first two lines -- variable declarations -- could be placed near the 
top of refdbxml for ease of maintainability.  The remaining lines need 
no further editing even if the list of rtf and pdf FO processors changes.
Here is the output if I specify FO processor = jfor and output format = 
pdf :
........................................
Specified FO processor: jfor.
Specified output format: pdf.
Error: jfor does not produce pdf output.
........................................
Other than that, I think it might do for now :-) .
Regards,
David
 | 
| 
      
      
      From: Markus H. <mar...@mh...> - 2004-03-05 23:41:11
       | 
| David Nebauer writes: > I've now tested the Makefile against my new refdbxml and refdbxmlrc > files using all the xslt and fo processors included to date. > > This includes: xalan, xt, saxon, saxon-xerces, xsltproc, passivetex, > fop, xep and jfor. > Do you have the classpaths for all the Java apps handy? I'd like to add example classpaths for each processor to the refdbxmlrc config file. > The only thing still bugging me is the theoretical possibility of > invoking refdbxml with a mismatch between the fo processor and output > type (eg. jfor processor with pdf output). Something like the following > code could be inserted at the start of process_print: > I've added that too. > Other than that, I think it might do for now :-) . > If you think so... Thanks a lot for your work. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de | 
| 
      
      
      From: David N. <dav...@bi...> - 2004-03-06 07:31:08
       | 
| Hi Markus,
>Do you have the classpaths for all the Java apps handy? I'd like to
>add example classpaths for each processor to the refdbxmlrc config
>file.
>
Here we go.  I'm going to include some comments and write the whole 
thing as if the reader is a relative newcomer to *nix who knows just 
enough to install software, create symlinks and manipulate files.  Where 
available, I'll indicate relevant Debian packages.
...................................................................................
In these examples, version numbers are often left out of jar file names, 
eg. logkit-1.1.jar would be logkit.jar.  The short form is a symlink to 
the longer titled file.  This can be done by the installation script or 
by the user.
In example classpaths, each component is put on a separate line for 
clarity.  When creating your own classpath, do not use line breaks, 
continuation marks ("\") or whitespace (tabs or spaces).
Instructions for xalan, saxon, saxon-xerces and fop are largely based on 
Bob Stayton's "DocBook XSL: The Complete Guide", Chapter 3 (Getting the 
tools working), see <http://www.sagehill.net/docbookxsl/index.html>.
xalan
    requires: xalan2.jar
    xalan2.jar
          - Important: this is the docbook stylesheets extension version
          - look for it in 'extensions' directory of docbook xsl stylesheets
          - debian package: docbook-xsl
    example classpath
          
/usr/share/sgml/docbook/stylesheet/xsl/nwalsh/extensions/xalan2.jar
saxon
    requires: saxon.jar, saxonXXX.jar, resolver.jar, (directory: user 
catalogs)
    saxon.jar
          - debian package: lib-saxon-java
    saxonXXX.jar  (where 'XXX' is version number)
          - docbook stylesheet saxon extension
          - found in 'extensions' subdirectory of docbook xsl stylesheets
          - use jar with closest match to saxon version, eg. for saxon 
version 6.4.4-1 use saxon644.jar
          - debian package: docbook-xsl
    resolver.jar
          - Apache project's catalog resolver
          - debian package:  xml-commons-resolver
    (directory: user catalogs)
          - when using catalogs, saxon needs to find a file called 
'Catalog.properties' on the classpath
          - include directory containing 'Catalog.properties' file
          - see saxon documentation for further details
  
    example classpath:
            /usr/share/java/saxon.jar:\
            
/usr/share/sgml/docbook/stylesheet/xsl/nwalsh/extensions/saxon644.jar:\
            /usr/share/java/resolver.jar:\
            /home/user/xml/catalogs/
saxon-xerces
    requires: as per 'saxon' PLUS xercesImpl.jar
    xercesImpl.jar
          - Apache's Xerces XML parser
          - debian package: libxerces2-java
    example classpath:
            /usr/share/java/saxon.jar:\
            
/usr/share/sgml/docbook/stylesheet/xsl/nwalsh/extensions/saxon644.jar:\
            /usr/share/java/resolver.jar:\
            /usr/share/java/xercesImpl.jar:\
            /home/user/xml/catalogs/
xt
    requires: xt.jar, xp.jar
    xt.jar
          - James Clark's XSLT transformer
          - debian package: libxt-java
    xp.jar
          - James Clark's XML parser
          - debian package: none.  Download from 
<http://www.jclark.com/xml/xp/>
    example classpath:
          /usr/share/java/xt.jar:\
          /usr/share/java/xp.jar
fop
    requires: fop.jar, batik.jar, xercesImpl.jar, avalon-framework.jar
    fop.jar
          - base fop package
    batik.jar
          - fop support package
    xercesImpl.jar
          - xml parser packaged with fop
    avalon-framework.jar
          - fop support package
    (all .jar files)
          - debian package: none, all are part of fop binary distribution
          - download from <http://xml.apache.org/fop/>
    example classpath:
            /usr/local/java/fop/build/fop.jar:\
            /usr/local/java/fop/lib/batik.jar:\
            /usr/local/java/fop/lib/xercesImpl-2.2.1.jar:\
            /usr/local/java/fop/lib/avalon-framework-cvs-20020806.jar
jfor
    requires: jfor.jar, xerces.jar, logkit.jar
    jfor.jar
          - jfor base package
          - debian package: none.  Download from 
<http://sourceforge.net/projects/jfor>
    xerces.jar
          - Apache's xml parser
          - debian package: libxerces-java
    logkit.jar
          - Apache application logger
          - debian package: liblogkit-java
    example classpath:
          /usr/share/java/jfor.jar:\
          /usr/share/java/xerces.jar:\
          /usr/share/java/logkit.jar
   
...............................................................................................................
Take whatever you think appropriate.
Regards,
David.
 | 
| 
      
      
      From: David N. <dav...@bi...> - 2004-03-04 14:28:42
       | 
| Hi Markus, >I've updated the Perl script that generates the .xsl file and hope that the >generated file works for Saxon as well. I've sent you an updated >version by private mail. Please let me know whether or not it works. > > After installing that file, saxon happily processed the document to completion and the make process proceeded to conclusion. I've tested both html and pdf output pathways and both work. Thanks for the fix. Regards, David. P.S. Does this mean I'm the first person to try refdb/xml/saxon (at least beyond giving up when saxon failed)? | 
| 
      
      
      From: Markus H. <mar...@mh...> - 2004-03-05 00:39:02
       | 
| David Nebauer writes: > After installing that file, saxon happily processed the document to > completion and the make process proceeded to conclusion. I've tested > both html and pdf output pathways and both work. Thanks for the fix. > Great. I'll check in the new version of the Perl script then. > P.S. Does this mean I'm the first person to try refdb/xml/saxon (at > least beyond giving up when saxon failed)? > Apparently?! I've got no idea what people out there use for their XML processing. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de | 
| 
      
      
      From: David N. <dav...@bi...> - 2004-03-05 08:26:12
       | 
| Hi Markus,
>Thanks for that. I've added refdbxmlrc with some cosmetic changes to
>CVS. I've also integrated your refdbxml changes into the official
>version which also required some Makefile.am and configure.in
>hacking. I've fixed a few obvious typos in the file you sent and made
>some minor changes, like parametrizing the xep root variable.
>
I missed something very obvious that would remove the need to 
parameterise xep's root variable: the install process creates a shell 
script: 'xep.sh'.  It contains a customised launch command including 
classpath and ROOT parameters appropriate for that computer.  Here, for 
example, is the shell script as built on my system during the xep 
install process:
..........................................................................................................................
#!/bin/sh
# This script encapsulates a standard XEP call.
JAVA_HOME=/usr/local/java/j2sdk1.4.2_03/jre
XEP_HOME=/home/david/progs/apps/xep
CP=$JAVA_HOME/lib/tools.jar:$XEP_HOME/lib/xep374_trial.jar:$XEP_HOME/lib/saxon.jar:$XEP_HOME/lib/xt.jar
$JAVA_HOME/bin/java -classpath $CP com.renderx.xep.XSLDriver 
-DROOT=$XEP_HOME $*
..........................................................................................................................
Providing xep.sh is on the system path, xep can be invoked in 
process_print thus:
    xep.sh -fo $1 -pdf $2
This would remove the need to specify xep's root directory.
The only potential problem is that the installer does not place xep.sh 
in a standard system directory, like /usr/local/bin or /usr/bin.  IMO, 
however, that can rightfully be considered part of the xep install 
process rather than part of the refdb configure process.  If you changed 
the xep launch command to use xep.sh, perhaps a note in the init file 
could indicate the need to make sure xep.sh is on the system path?
Regards,
David.
 | 
| 
      
      
      From: Markus H. <mar...@mh...> - 2004-03-05 23:41:07
       | 
| David Nebauer writes: > Providing xep.sh is on the system path, xep can be invoked in > process_print thus: > > xep.sh -fo $1 -pdf $2 > > This would remove the need to specify xep's root directory. > > The only potential problem is that the installer does not place xep.sh > in a standard system directory, like /usr/local/bin or /usr/bin. IMO, > however, that can rightfully be considered part of the xep install > process rather than part of the refdb configure process. If you changed > the xep launch command to use xep.sh, perhaps a note in the init file > could indicate the need to make sure xep.sh is on the system path? > I've changed refdbxml to use xep.sh. The full path can be set at the top of the file. By default the variable is empty, i.e. xep.sh is searched for in your PATH. The simplest way to get xep.sh into your PATH (for all users) may be to create a symlink in /usr/local/bin. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de | 
| 
      
      
      From: David N. <dav...@bi...> - 2004-03-05 09:16:53
       | 
| Markus Hoenicka wrote:
>Thanks for that. I've added refdbxmlrc with some cosmetic changes to
>CVS. I've also integrated your refdbxml changes into the official
>version which also required some Makefile.am and configure.in
>hacking. I've fixed a few obvious typos in the file you sent and made
>some minor changes, like parametrizing the xep root variable. I've
>tested the updated script with xsltproc and FOP. I'm currently
>updating my xerces and Saxon installations, but I expect this will
>work too.
>  
>
I'm afraid that further testing has shown up some problems with my 
refdbxml script.  While I thoroughly tested the pdf output, I didn't 
test rtf output.  I'm doing so now and have discovered some errors:
1. The test for valid fo_processor does not include 'jfor'.  Here are 
the problem lines:
.........................................................................................................
if [ ! $fo_processor = "passivetex" ] && [ ! $fo_processor = "fop" ] && 
[ ! $fo_processor = "xep" ]; then
  echo "specify one of 'passivetex', 'fop', 'xep' with the -f option"
.........................................................................................................
and here's how it should read:
.........................................................................................................................................
if [ ! $fo_processor = "passivetex" ] && [ ! $fo_processor = "fop" ] && 
[ ! $fo_processor = "xep" ] && [ ! $fo_processor = "jfor" ]; then
                                                                                                   
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  echo "specify one of 'passivetex', 'fop', 'xep', 'jfor' with the -f 
option"
                                                 ^^^^^^^^
.........................................................................................................................................
2. The test for whether classpaths were extracted from init file is 
defective.  The problem lines are here:
.............................................................
# Set classpath variables to default if not already specified
if ! [ -n "$xslt_processor" ]; then
                 ^^^^^^^^^
    xslt_processor=$classpath
         ^^^^^^^^^
fi
if ! [ -n "$fo_processor" ]; then
               ^^^^^^^^^
    fo_processor=$classpath
       ^^^^^^^^^
fi
.............................................................
and the corrected lines here:
.............................................................
# Set classpath variables to default if not already specified
if ! [ -n "$xslt_classpath" ]; then
                 ^^^^^^^^^
    xslt_classpath=$classpath
         ^^^^^^^^^
fi
if ! [ -n "$fo_classpath" ]; then
               ^^^^^^^^^
    fo_classpath=$classpath
       ^^^^^^^^^
fi
.............................................................
3. The jfor command still used the (old) default classpath instead of 
the fo classpath.  The offending lines:
...............................................................................
process_print () {
    case $fo_processor in
    jfor )
        java -cp "$classpath" ch.codeconsult.jfor.main.CmdLineConverter 
$1 $2;;
...............................................................................
and the corrected version:
..................................................................................
process_print () {
    case $fo_processor in
    jfor )
        java -cp "$fo_classpath" 
ch.codeconsult.jfor.main.CmdLineConverter $1 $2;;
                   ^^^
..................................................................................
You may have picked up some (or all) of these when you diplomatically 
refer to "obvious typos".
Apologies for the inadequate testing.
By the way, the current jfor is little difficult to get running, mainly 
owing to inadequate (actually, mostly absent) documentation.  I found 
the clue I needed in a jfor user-group posting (archived on GMane) about 
the Windows version!  It's obviously nothing to do with refdb directly, 
except that the Makefile relies on jfor for rtf output.  I'll post 
details direct to refdb-users with an informative heading for anyone 
else who's trying to set jfor up.
Regards,
David.
 | 
| 
      
      
      From: Markus H. <mar...@mh...> - 2004-03-05 23:41:09
       | 
| David Nebauer writes:
 > if [ ! $fo_processor = "passivetex" ] && [ ! $fo_processor = "fop" ] && 
 > [ ! $fo_processor = "xep" ] && [ ! $fo_processor = "jfor" ]; then
 >                                                                                                    
 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 >   echo "specify one of 'passivetex', 'fop', 'xep', 'jfor' with the -f 
 > option"
 >                                                  ^^^^^^^^
Ok, I've fixed these lines.
 > # Set classpath variables to default if not already specified
 > if ! [ -n "$xslt_classpath" ]; then
 >                  ^^^^^^^^^
 >     xslt_classpath=$classpath
 >          ^^^^^^^^^
 > fi
 > if ! [ -n "$fo_classpath" ]; then
 >                ^^^^^^^^^
 >     fo_classpath=$classpath
 >        ^^^^^^^^^
 > fi
These were the "obvious typos"...
 > process_print () {
 >     case $fo_processor in
 >     jfor )
 >         java -cp "$fo_classpath" 
 > ch.codeconsult.jfor.main.CmdLineConverter $1 $2;;
 >                    ^^^
I've fixed this as well.
regards,
Markus
-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de
 |