Steven Noels wrote:
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?
In perfect do-ocracy, who makes it work first, gets my vote. :-)
--
Stefano.
