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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

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

Subject: Re: DOCBOOK: Re: custom xsl stylesheet and import path

On Wed, May 01, 2002 at 03:47:23AM +0000, Matt G. wrote:
> On Fri, May 03, 2002 at 11:06:02AM -0700, Bob Stayton wrote:
> >  
> > That's neat trick.
> > But I don't see an option with Saxon or xsltproc to 
> > define an entity on the command line.  Which processor
> > can do that?
> Sorry, I guess I might have had that confused with defining
> a global variable, which is a command-line option supported
> by both openjade and Xalan.  IMO, XML-processing tools
> should provide that feature (i.e. entity definition via the
> command-line).  You could always write a wrapper script
> that adds the entity definition to the internal subset of a
> copy of the document, before transforming it.  It's ugly,
> because you couldn't use a real XML parser to do that,
> since, by definition, the document will contain
> irresolvable entity references.  In usage, this ugliness
> would be entirely hidden, though.
> Anyhow, treating it as an external entity does work, and
> you can put the generation of that in your makefile(s) or
> document build script(s).

I've used another technique with XML catalogs that simulates the
use of variables in xsl:import with a wrapper script:

1.  Use a script whose first step is to take the desired
path value and generate a temporary XML catalog file that
maps the hardcoded xsl:import path to your new path value.

2.  Have your script execute your XSL process
using that XML catalog.

3.  Then the script deletes the temporary catalog file.

XML catalogs can map any stylesheet path to another path.
If your <xsl:import> looks like this:

  <xsl:import href="/usr/share/docbook/html/docbook.xsl"/>

And you want to instead use:


Then this catalog entry in the temporary catalog file
will map it:


Since the generation of the catalog file can be controlled
by any number of variables in the script, you have complete control
over the rewritePrefix value.

BTW, if you are already using an XML catalog file for other
purposes, then just add a line like this to your
temporary catalog:

 <nextCatalog catalog = "/path/to/your/regular/catalog.xml"/>

Of course, this setup requires a processor and
configuration that can use XML catalogs.
But they are pretty much required when you
need portability.


Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
Caldera International, Inc.                 fax:   (831) 429-1887
                                            email: bobs@caldera.com

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

Powered by eList eXpress LLC