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] | [Elist Home]


Subject: Re: DOCBOOK-APPS: EntityResolver for XSLT processor and catalog files


Hi,

Thanks for the wrapper code below. Just had occasion to get it working
with xalan 2.2D6. Do you know if the entity resolver will fall back on
the standard URL if the catalog entry is not found?

Thanks,

Eric

"M.-A. DARCHE" wrote:
> 
> On 20010603 01:20 (Sunday), ben wrote:
> > FYI, I've seen the reason why xalan was failing: it is due to the fact that
> > xalan creates only a new EntityResolver object, but doesn't provide a catalog
> > to the resolver (specific to the catalog entity resolver). I've fixed the
> > problem by extending the CatalogEntityResolver class so that by default the
> > catalogs are the system ones (xml.catalog.files). If someone is interested, I
> > can send the extended class.
> 
> Hello,
> 
> I've checked the mailing list archive and Ben's statement is may be the
> best detailed description of *using Xalan with catalog files support*.
> So I think that there is maybe a lack of information on the subject.
> Having spend some time to solve this too I think the explanations below
> might help others.
> 
> I've also augmented Bob Stayton's
> "Using XSL tools to publish DocBook documents".
> The modified document is here
> http://ma.darche.free.fr/xml/publishing-augmented.xml
> I hope it will make it into the docbook-xsl documentation :-)
> 
> As for the EntityResolver wrapper class named here ConfCatEntityResolver,
> I do believe that it should be included (or an equivalent) in the java
> catalog classes distribution (in the catalog-apps.jar) because :
> - it's not straightforward to use the java catalog classes with an XSL
>   processor
> - not everyone want to write code before publishing
> - it might be a good thing to have the same classname for everyone so
>   operating systems distributions can standardize their scripts,
>   environment, etc.
> 
> Norm, would it be possible to have the java catalog classes hosted on
> http://sourceforge.net/projects/docbook/ ?
> They will be more widely known and besides that would be more logical
> if we are to expect the C or C++ implementation ;-)
> 
> Cheers,
> 
> =======================================================================
> 
> Xalan example
> -------------
> Here is a simple example of a Unix command line to produce HTML. You'll
> need to alter your CLASSPATH environment variable to include the path to
> where you put the specified .jar files.
> 
> CLASSPATH=xalan.jar:xerces.jar
> export CLASSPATH
> java \
> org.apache.xalan.xslt.Process -html \
> -in filename.xml \
> -xsl docbook/html/docbook.xsl \
> -out output.html
> 
> Catalog files support
> ---------------------
> XSLT processors are more efficiently used with catalog files. In order
> to benefit from catalog files one can use the Java Catalog classes that
> Arbortext released to the XML community.
> http://www.arbortext.com/Think_Tank/XML_Resources/Issue_Three/issue_three.html
> The example that follows is the Xalan example taken a step further.
> In this example catalog should
> be replaced by your system catalog file which could be
> /usr/lib/sgml/catalog.
> 
> CLASSPATH=xalan.jar:xerces.jar:catalog.jar:catalog-apps.jar
> export CLASSPATH
> java \
> -Dxml.catalog.debug=0 \
> -Dxml.catalog.override=yes \
> -Dxml.catalog.files=catalog \
> org.apache.xalan.xslt.Process -html \
> -entityresolver ConfCatEntityResolver \
> -in filename.xml \
> -xsl docbook/html/docbook.xsl \
> -out output.html
> 
>  Please note that the com.arbortext.catalog.CatalogEntityResolver java
>  class cannot be passed directly to Xalan because it doesn't take any
>  configuration in charge. So one has to pass a custom made
>  EntityResolver to the XSL parser. This is this class listing that
>  follows :
> 
> ConfCatEntityResolver
> ---------------------
> 
> import java.io.IOException;
> import java.net.MalformedURLException;
> 
> import org.xml.sax.EntityResolver;
> 
> import com.arbortext.catalog.Catalog;
> import com.arbortext.catalog.CatalogEntityResolver;
> 
> /**
>  * ConfCatEntityResolver stands for Configured CatalogEntityResolver
>  * and is a wrapper around the CatalogEntityResolver class.<br />
>  *
>  * This wrapper's purpose is to let any XSLT processor use it
>  * as an EntityResolver right out of the box, without the parser needing
>  * to configure the specific CatalogEntityResolver.
>  */
> public class ConfCatEntityResolver extends CatalogEntityResolver {
> 
>     public ConfCatEntityResolver() {
>         super();
>         Catalog catalog = new Catalog();
>         try {
>             catalog.loadSystemCatalogs();
>             this.setCatalog(catalog);
>         } catch
>         (MalformedURLException
>          muex) {
>             muex.printStackTrace();
>         } catch
>         (IOException
>          ioex) {
>             ioex.printStackTrace();
>         }
> 
>     }
> 
> }
> 
> --
> Marc-Aurčle DARCHE  <http://ma.darche.free.fr>
> AFUL <http://www.aful.org>
> Association Francophone des Utilisateurs de Linux/Logiciels Libres
> French speaking Linux and Free Software Users' Association


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


Powered by eList eXpress LLC