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

Subject: Re: [docbook-apps] processing chapters in parallel

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:


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

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

----- 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"
 <xsl:variable name="chapid" select="//d:chapter/@xml:id" />
 <xsl:variable name="chapelem"
 <xsl:value-of select="$chapelem/@number"/>

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

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

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

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

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

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