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] Apache modules for serving DocBook

On Monday 08 November 2004 15:45, Frans Englich wrote:
> 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?

he, he :-) Soon as the devs at Forrest have XHTML as internal format. Judging 
by the timeline, 0.7 and 0.8 will see this happening.

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

Not exactly.

<snip/> Description of problem.

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

Cocoon alone does not solve the problem. Dynamic transformation of large 
docbook modular repositories with olinks etc. is to heavy for the servlet. 
You have to make the job easier.

I propose the following solution. It may or may not meet your requirements, 
depending on how important it is that you have immediate reflection of 
updates in the servlet environment.

I assume that the publishing environment has a development and release cycle. 
If this is so, then sources only need to go to production phase on release.
When release happens, do svn export to get a pristine tree of the revision. 
Then run standard transformations with output to a target directory where 
your forrest project expects to find the documents.

Since the forrest menus and tabs are defined in xml documents it is easy to 
automatically add any navigation changes needed during the make process.

It's not perfect, but you can get output that is of better quality than is 
currently supported by forrest. By this I mean that all inter-document cross 
references, glossterms etc will be resolved correctly. The servlet will also 
have less work to do and user response will be much better.

Sean Wheller

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