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

Subject: Re: [docbook] Easiest way to define ProductName variable?

Hi all,

we are using for this usage a simple XSL trick:

  <xsl:template match="parameter[@role='variable-text']">
    <xsl:variable select="." name="id"></xsl:variable>
    <xsl:value-of select="//*[@id=$id]"/>

How to use:
1) create your variable, wherever you want in your document, though it's generally placed in the <info> header, for example <productname xml:id="PN">Calenco</productname>
2) Call it: <parameter role="variable-text">PN</parameter>

You can combine this with profiling by using various profiled elements inside the source element...


Camille Bégnis
Tél: +33 (0)
5, rue de la Touloubre
13770 Venelles
Le 24/01/2015 19:01, Aaron DaMommio a écrit :
We are also, at Alcatel-Lucent/Motive, using a simple (ant) substitution. I'm finding that this is very flexible. I can make it happen during a build step that happens after xi:includes are resolved, and also can use ant's property system to set the values to be substituted. Each book's ant build.xml imports a global build file to get global properties, and has the option of setting those properties' values BEFORE the import, so that it can override the global settings for a substitution when needed. 
--Aaron DaMommio

On Fri, Jan 23, 2015 at 6:28 PM, Mary Tabasko <tabasko@telerama.com> wrote:
Hi, all.

Barton Wright said:

> But, to be honest, for the very large, thousand-page DocBook doc
> set I maintain, we found that the profiling overhead for simple
> variable substitution put far too much of a burden on our doc build
> times, and we gave up on it.[...]
> For variables, we ended up with a simple Perl script substitution
> that runs on a copy of our doc source files.

We also avoid profiling/conditionals because we have very large docs, and the
two-pass processing is something we'd like to avoid. Two approaches
we have used involve having multiple files with the entities and the desired
values in them, one for each variant.

Approach one: create a catalog file for each variant that resolves a file entity
for the entity file (terrible sentence, sorry) to the desired variant. Point to the
desired catalog at build time.

Approach two: (we use this for documents that are assembled out of many
pieces into a staging area: simply copy the desired entity file into the staging area
as a "prebuild" step.)

Hope that helps somebody. Good luck, Mary!

-- Mary Tabasko

To unsubscribe, e-mail: docbook-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-help@lists.oasis-open.org

Aaron DaMommio: Husband, father, writer, juggler, and expert washer of dishes.
- My blog: http://aarondamommio.blogspot.com
- Need a juggler?  http://amazingaaronjuggler.blogspot.com/

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