Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
In-Reply-To: <4283748F.9090301@apache.org>
References: <2f44faadc4a27ef74ba7ef13b742cdd9@efurbishment.com>
 <a753b7f80505111823427a3c80@mail.gmail.com> <4282C5DE.5040709@apache.org>
 <200505121223.33206.niclas@hedhman.org>
 <a753b7f8050511213359da5487@mail.gmail.com>
 <e38fc1bf22999829fcaaca03e496d1eb@apache.org>
 <5bd9371a02665db32b5af57b59dded1d@efurbishment.com>
 <4283748F.9090301@apache.org>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <cad9f12c677dce4704354dcbbf334261@outerthought.org>
Content-Transfer-Encoding: 7bit
Cc: Daisy@UGent.be:open source CMS - general mailinglist
 <daisy@lists.cocoondev.org>
From: Steven Noels <stevenn@outerthought.org>
Subject: Forrest & Daisy integration scenarios
Date: Fri, 13 May 2005 11:51:16 +0200
To: dev@cocoon.apache.org

On 12 May 2005, at 17:21, Stefano Mazzocchi wrote:

> But it's also true that editing xml files in a svn repository sucks as 
> an editing tool. Using wiki (or daisy or other solutions) is much 
> better.
>
> I like the notion of
>
>  daisy -> forrest -> out
>
> makes very good sense.

It does, yet there's obvious huge bits of overlap between Forrest and 
Daisy's publishing mechanism. IMO, Daisy is perfectly able to host 
Cocoon's documentation, both for editing and publishing.

The bridge between Daisy and Forrest could be a Forrest exporter: i.e. 
a tool which aggregates and renders a Daisy site and converts it into a 
Forrest source xdocs + site.xml tree. This tool might find some of its 
inspiration in the work we're planning for the Daisy Books tool.

If however the Cocoon documentation only consists of Daisy-managed 
content, I wonder what this exporter would buy us in the short term 
compared with a live Daisy site + custom skin, possibly wget-ed into 
static HTML for SVN storage.

There's a few possible scenarios:

                    ------------------------------
             -------| editing wiki (plain daisy) | (1)
--------    |      ------------------------------
| repo |----|
--------    |      ----------------------------------   wget   
---------------
             -------| wiki + custom cocoon-site skin |----------| static 
HTML | (2)
             |      ----------------------------------          
---------------
             |
             |      ----------------------------------------   wget   
---------------
             -------| publish-only lib + custom render app |----------| 
static HTML | (3)
             |      ----------------------------------------          
---------------
             |
             |      --------------------   forrest   ---------------
             -------| forrest exporter |-------------| static HTML | (4)
                    --------------------             ---------------

(1) exists already, (2) is low-hanging fruit, (3) is something we're 
working on for the next release, and (4) is possible as well, but 
requires more work.

In (2), I consider the wget step to be optional for the live Cocoon 
documentation site, and only required when we want to produce static 
HTML for inclusion in the distribution, or if we want to store the 
site's content in SVN as well. Both make sense to me.

In the current Daisy Forrest plugin, the interface between Forrest and 
Daisy is a rendered, jtidied Wiki page. That (a) is not a very solid 
contract IMHO, and (b) creates duplication of effort, as the site 
structure needs to be maintained in both Daisy and Forrest.

Of course, if the Cocoon documentation would be a mixture of Daisy- and 
non-Daisy managed documents (like Word/OO files), we would need to come 
up with other scenarios.

What do people think?

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source Java & XML            An Orixo Member
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org