Re: [docbook-apps] processing chapters in parallel

["Bob Stayton" <bobs@sagehill.net>]

Hi Tim,
I have a couple of improvements to suggest.

1.  If you are not using a sitemap, you could replace the "//" in the olink_data 
selection with specific elements. Any time you use "//" the processor may descend 
deeply into the structure before finding the element it seeks, which is likely near 
the top.  Depending on what you have in your olink database file, you may just be able 
to use:

  select="document($target.database.document)/targetset/document[@targetdoc=$current.docid]"


2.  <xsl:variable name="chapid" select="//d:chapter/@xml:id" />

This is the chapter id of the current chapter, right?  While your select will work, it 
assumes it is opening a document that contains only that one chapter, which may not 
always be true.  Since this template matches on the current chapter, you don't need to 
select the chapter element again.  You can just select="@xml:id" because the current 
context is the matched chapter element.

3.  If you want to further optimize, I will mention that the olink data is indexed 
with xsl:key the first time it is opened, so you can use XSL's key() function to 
extract data from it very quickly. That is how olinks are resolved.  The olink 
database is opened only once per run, and the key makes lookup very quick, so you 
should not see much performance hit except in opening the database once.

The xsl:key is declared in common/olink.xsl as:

<xsl:key name="targetptr-key"  match="div|obj"
        use="concat(ancestor::document/@targetdoc, '/', @targetptr, '/', 
ancestor::document/@lang)" />

The lookup string you want to use to retrieve a div or obj element is a compound key 
made up of three strings separated by slashes, and looks like 
"targetdoc/targetptr/lang".  This ensures each key is unique in the database.

Here "lang" is the value of an @lang attribute on the *document* element in your 
database, not in content.  The lang attribute on document must be added by hand, and 
it is only necessary if you are processing translated content and your database has 
copies of the same targetdoc but in different languages. Then @lang is needed to 
select the right set of translated data.   If that is not the case, then lang is empty 
(the usual case) and  the key looks like "targetdoc/targetptr/"  (keep the trailing 
slash).

So your template could be reduced to (untested):

<xsl:template match="d:chapter" mode="label.markup">
 <xsl:value-of select="key('targetptr-key', concat($current.docid, '/', @xml:id, 
'/')/@number"/>
</xsl:template>

The key() function uses the 'targetptr-key' index, which is generated the first time 
it is referenced, so you need not use the document() function in your template.

The lookup string consists of the value of $current.docid (which you set on the 
command line, I presume), slash, the xml:id of the current chapter element, and a 
trailing slash.

The key() function returns the div element from the database for that chapter.

Then /@number retrieves the chapter number from that div element.  There is no need 
for exsl:node-set().


Bob Stayton
Sagehill Enterprises
bobs@sagehill.net


----- Original Message ----- 
From: "Tim Arnold" <jtim.arnold@gmail.com>
To: "Bob Stayton" <bobs@sagehill.net>
Cc: <docbook-apps@lists.oasis-open.org>
Sent: Monday, October 17, 2011 1:00 PM
Subject: Re: [docbook-apps] processing chapters in parallel


Hi Bob, everyone,
Thanks for your guidelines. I will create toc, etc by using the olink
data after processing the chapters in parallel.

As for the chapter numbering issue, I seem to have chapter numbering
working now, using the following code. Please take a look and let me
know if I'm missing something or have done something clunky. Mainly I
fear that this template will cause performance problems since I expect
it is a pretty expensive template to call often, with it opening that
big olinkdb.xml file every time.

First I open the entire database of olinks, which spans several books.
The first variable is the nodeset of olink data for the current book.
The second variable is the id for the current chapter.
The third variable is the element in the olink data that corresponds
to the current chapter.

The template simply returns the value of the number attribute of the element.

<xsl:template match="d:chapter" mode="label.markup" >
 <xsl:variable name="olink_data"
select="document($target.database.document)//document[@targetdoc=$current.docid]"
/>
 <xsl:variable name="chapid" select="//d:chapter/@xml:id" />
 <xsl:variable name="chapelem"
select="exslt:node-set($olink_data//div[@targetptr=$chapid])"/>
 <xsl:value-of select="$chapelem/@number"/>
</xsl:template>

Thanks for any feedback or optimizations.
--Tim Arnold


On Thu, Aug 25, 2011 at 1:22 PM, Bob Stayton <bobs@sagehill.net> wrote:
> Hi Tim,
> Actually, you could generate the book's TOC from the information in the
> olink database. The <div> elements have the same nested structure as the
> book, and the title and hrefs are there.
>
> Regarding the chapter numbers, those could be looked up without being passed
> in individually. If your stylesheet opens the olink database, it could use
> xpath to locate the div whose @element is chapter and whose @targetptr
> matches the chapter id attribute that is currently being processed. The
> templates in common/olink.xsl show how to open it and access elements from
> it.
>
> Since the chapter number might be used in several places (figure and table
> numbers, section numbers), you should customize the template with
> match="chapter" and mode="label.markup" to output the chapter number from
> the olink database. That mode is used by all the templates that need the
> chapter number.
>
> Bob Stayton
> Sagehill Enterprises
> bobs@sagehill.net
>
>
> ----- Original Message ----- From: "Tim Arnold" <jtim.arnold@gmail.com>
> To: <docbook-apps@lists.oasis-open.org>
> Sent: Wednesday, August 17, 2011 12:57 PM
> Subject: [docbook-apps] processing chapters in parallel
>
>
> > Hi,
> > I have a few large books (~13mb) that I'm processing to html with the
> > 1.76.1 stylesheets. Obviously that takes a while, so I wanted to ask
> > about what issues will I need to take care of if I process the book
> > chapter by chapter instead of as one monolithic book.
> >
> > I have the book.xml, and the separate book_chapter.xml files with an
> > olinkdb.xml database for the olinks (generated from the book.xml
> > file).
> >
> > The two problems I can see so far is that
> > (1) I won't have a book table of contents and
> > (2) I'll have to figure out how to pass in each chapter's number to
> > match the numbers in the generated olinkdb.xml file
> >
> > These seem like solvable problems. Is there anything I'm missing that
> > might bite me later on?
> >
> > thanks for any ideas, information.
> > --Tim Arnold
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org