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]"/>

        </xsl:template>

      

      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...

      

      HTH,

      

      

        

          
NeoDoc

          
Camille
                  Bégnis

           
          


           
          
Tél: +33
                (0)4.42.52.24.20

           
          
5, rue de la Touloubre

           
          
13770
                Venelles

           
          
France

           
          
http://www.neodoc.fr/

        

      

      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 <>
          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: 

            For additional commands, e-mail: 

            

          
        

        

        
        

        

        -- 

        
--------------------------------------

          Aaron DaMommio: Husband, father, writer, juggler, and expert
          washer of dishes.

          - My blog: http://aarondamommio.blogspot.com

          - Need a juggler?  http://amazingaaronjuggler.blogspot.com/

          =======================================