cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: [RT] The Cocoon Handbook
Date Fri, 25 Jun 2004 14:37:04 GMT
Sylvain Wallez wrote:

> Vadim Gritsenko wrote:
>> Sylvain Wallez wrote:
>>> Now we have that nice thing called OpenOffice that is a 
>>> wordprocessor storing its content as XML in a zip archive. We've 
>>> used it as a front-end for a CMS, providing template documents with 
>>> style sheets that have to be used. These styles match the structure 
>>> of the target XML document that is produced from the OO file. This 
>>> solution just rocks, as anybody (even a boss :-) is able to write 
>>> content in a userfriendly and productive environment with spell 
>>> checking, typing completion, etc etc. On the CMS side, the sxw 
>>> archive is exploded, the XML content is transformed into the target 
>>> markup (e.g. DocBook) and images are stored.
>>> Sure, for the Cocoon docs, we cannot wait to have a CMS setup and 
>>> ready, or we'll never have docs ;-) What is rather simple, however, 
>>> is to have some offline processing (based on the CLI) that would do 
>>> the exploding/recomposition job to allow editing Cocoon docs with a 
>>> real wordprocessor.
>> It would be simplier to store docs in sxw file itself; no 
>> recomposition is necessary, and html/pdf publishing out of sxw 
>> "repository" can be added to forrest.
> The problem is that it requires storing the sxw as a binary file, 
> which doesn't help to track changes.
> A mid-term solution can be to dezip the sxw and store it's various 
> components as is. The exploding/recomposition process would then 
> simply be unzip/zip.

Another way could be storing the whole document as one file by using 
import/export filters that creates a single XML document and you don't 
have to deal with the whole bunch of docs.


View raw message