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
