Re: [docbook-apps] Apache modules for serving DocBook

[Frans Englich <frans dot englich at telia dot com>]

On Monday 08 November 2004 08:42, Sean Wheller wrote:
> On Monday 08 November 2004 09:24, Frans Englich wrote:
> > On Sunday 07 November 2004 22:07, Tristan Fiedler wrote:
> > > I have a series of chapters (marked up with DocBook XML) stored in a
> > > mysql database. ?I would like them to be rendered as both HTML and pdf
> > > through a webpage. This is creating an online book.
> > >
> > > What is the preferred / efficient method to automate this using apache
> > > ? ?Do I need to run an XSLT and XSLFO each time? ?I would prefer not to
> > > store the HTML and pdf, but create them on the fly if that is not to
> > > time consuming. ?Most chapters are about 2500 words of text, plus
> > > markup, which can be up to 50% more. ?Images are also present.
> >
> > Serving Docbook dynamically was discussed some time ago:
> > http://sources.redhat.com/ml/docbook-apps/2004-q3/msg00609.html
> > http://sources.redhat.com/ml/docbook-apps/2004-q4/msg00006.html
> >
> > If you come up with any solution -- let the list know. The best
> > alternative is the one described by Bob, but it means restraining the
> > Docbook vocabulary and doing heavy customizations.
>
> At present Forrest does have Docbook support. Though this is limited in the
> quality of the transformation.
>
> At Apache Forrest we are in the process of moving the internal format used
> within the system to XHTML.
>
> The idea is that any application able to transform to XHTML will be able to
> input its content to Forrest.
>
> In the case of docbook the FULL DOCBOOK plugin will use cocoon pipes to
> transform docbook xml to xhtml using the docbook xhtml xsl's and have it
> serialized into the aggregation mechanism of forrest. The final outcome
> should be docbook content skinned by forrest.
>
> docbook xml -> xhtml -> xhtml skinned
>
> A new plugin architecture has been devised for forrest. The FULL DOCBOOK
> plugin will fit into this architecture. The plugin is comprised of a
> Forrest sitemap, docbook custom layers, docbook dtd's, and docbook xsl's.
>
> Unfortunately this plugin will not be usable until the project impliments
> XHTML as an internal format and proper processing of the docbook xhtml
> exists in the core of the system.

This surely sounds incredible useful. Something I definitely will look into 
for the project I'm working on(a new version of KDE's developer site). Is 
there a rough timescale on when it will reach "reasonable" production 
quality?

However, I wonder if it changes the problem discussed in those thread: serving 
large Docbook projects dynamically, with reasonable performance.

The problem is that a transformation of a whole Docbook project takes very 
long time, and when the sources are worked on continually, that means the 
whole cache is invalidated as soon as one file is changed. It appears to be a 
problem having its roots in the design of XSLT and Docbook's XSLTs. 

This is what mostly is needed in my case -- a way to serve dynamically with 
reasonable speed, such that people can continuously update the site.

In short; the upcoming advancements in Forrest, it doesn't change the fact 
that if one file is modified, which is XIncluded(or Cocoon's CIncludes) into 
a larger Docbook project, then /all/ the sources must be iterated by the 
XSLTs, right?

Of course, a god-like caching mechanism which caches on somekind of 
element/template level, instead of file/transformation, would solve it..


Cheers,

		Frans