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


Subject: Re: DOCBOOK-APPS: More performance issues with XSL 1.52.2


On Fri, Jul 26, 2002 at 02:29:35PM +0200, Kraa de Simon wrote:
> Hello,
> 
> Please advise.
> 
> Currently I have one large book (about 5000 html files) and just don't have
> enough time to generate the whole document every night.
> 
> Do I understand correctly that splitting the book up into a set of books
> won't help me out here because I still have to generate the whole set in one
> go?

That's correct, if you are trying to cross reference among the books
using <xref> and <link>.  Those elements use the ID/IDREF
mechanism to resolve links, and the ID and IDREF must be
in the same document.
 
> Because some of the chapters (books) are quite static / don't change often I
> would like to skip those.
> 
> Do I understand correctly that using olink you can accomplish this?
> 
> For example:
> 
> book
>   chapter 1 - dynamic -> process
>   chapter 2 - dynamic -> process
>   chapter 3 - static  -> skip
>   chapter 4 - dynamic -> process
> 
> or
> 
> set
>   book1 -> process
>     chapter 1 - dynamic -> process
>     chapter 2 - dynamic -> process
>     chapter 3 - static  -> skip
>     chapter 4 - dynamic -> process
>   book2 -> process
>     chapter 1 - dynamic -> process
>     chapter 2 - dynamic -> process
>   book3 -> skip
>     chapter 1
>     chapter 2

Currently the olink in the XSL stylesheets can't quite
do what you want.  The scenario where it works best
looks like this:

book1 -> process
book2 -> process
book3 -> skip

This is a collection of books not inside of a set element, and
where you want to form links between the books.
By using olink for those links between books, you can
avoid having to create one huge set document just to form
links.  With this scenario, you can process a single book
whenever something changes in that book.

But you have to be careful, because when you start using
olinks, you create dependencies between your books.  Let's
say you change a chapter title in book1 and reprocess that
book.  If your book3 has an olink to that chapter, and that
olink element contains no text, then the chapter title link
text that was generated the last time book3 was processed
is now wrong and needs to be updated.  If you use
Makefiles, you can have book3 be dependent on book1's
target data file, which is generated for olinking.
If you are careful to not alter the timestamp on the target
data file unless it actually changes, then the dependency
works.  See
http://www.sagehill.net/xml/docbookxsl/Olinking.html (the
section on Using Makefiles) for an example.

You can also split a book up into chapter files, and use
olinks to link among the book's chapter files.  If you use
XInclude instead of system entities to assemble the book,
then you can have fully valid chapter files.  That's a nice
feature for writing and editing.

But processing a single chapter with the current
stylesheets will always yield "Chapter 1" in the output,
because that's the 'document' the processor is seeing.
There are two ways around that.
One way is to put a fixed "label" attribute on
each chapter element, but that loses autonumbering.
Who wants to manually maintain chapter numbers?  Not me.
Or you can process your master book file with the 'rootid'
parameter to select a single chapter for output.
This still loads and parses the entire book though,
so I don't think it speeds things up a lot.

Since all we need is to set the chapter number,
I have in mind a new parameter that tells the stylesheet
to get the chapter number from the target data file
for the book.  But that feature isn't implemented yet.

Taking that idea a step further, you could construct a mega table
of contents from your target database.  It contains all
the hierarchy, text, and URL information it needs to
do that.   So theoretically you could generate something
like a complete set TOC for your collection of books,
even though you have no set element.



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
> 

> -----Oorspronkelijk bericht-----
> Van: Bob Stayton [mailto:bobs@caldera.com]
> Verzonden: woensdag 24 juli 2002 22:57
> Aan: Jeff Beal; DocBook Mailing List (E-mail)
> Onderwerp: Re: DOCBOOK-APPS: More performance issues with XSL 1.52.2
> 
> 
> On Wed, Jul 24, 2002 at 03:36:17PM -0400, Jeff Beal wrote:
> > In a previous post, I noted that my build time increased by a ridiculous
> > amount (5 hours to 50, more or less) when upgrading from the 1.48
> > stylesheets to the 1.52.2 stylesheets.  With a little bit of customization
> > (discussed on those threads) I was able to get my time to something
> slightly
> > faster than the 1.48 stylesheets.  However, that allowed the build to go
> > further than I had allowed it to go, revealing grossly huge memory
> > utilization.  Instead of using around 350MB of RAM, it now maxes out at
> > 1.4GB of RAM, and Java can't seem to handle any more than that - it
> crashes.
> > (I had to play with the -X parameters to get it to go as high as 1.4GB).
> > I've tried a couple of different things, including looking for more
> > customizations and using different Saxon switches, and the long and short
> of
> > it all seems to be that I can't use the 1.52.2 stylesheets with Saxon.
> I'd
> > switch to xsltproc at this point, but I really need the extension
> functions
> > Norm provides, and one of my own that handles all of my graphics in a
> rather
> > nice way.
> >  
> > Any ideas here?
> 
> It sounds like you are processing very large documents,
> such as sets of books?  You might consider processing
> smaller modules and using olinks to connect them.
> The 1.52 stylesheets have a new olink implementation 
> that makes olinking easier.  I haven't publicized it
> yet because 1.52.2 has a little glitch that's fixed
> in CVS, but I can help you try it out if you are
> interested.
> 
> -- 
> 
> 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

-- 

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