Re: [Refdb-users] User feedback 3

[David N. <dav...@bi...>]

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.