cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [daisy] Forrest & Daisy integration scenarios
Date Fri, 13 May 2005 14:25:31 GMT
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.

There is overlap, but Forrest is, in my opinion, far superior in the
flexibility of its publishing and has the added ability to integrate
content from multiple sources and make it available in multiple formats.
Since the cocoon docs already consist of Wiki docs, Xdocs, HTML docs,
Daisy docs and who knows what else this ability to utilise multiple
input formats is critical.

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

As Steven will probably know I recently started a thread about this and
other related areas over on the Daisy dev list. We'll see where that goes.

> If however the Cocoon documentation only consists of Daisy-managed 
> content, 

It doesn't, and I doubt it ever will.

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

Pulling together all the different content available and making it uniform.

Allowing the different content to be presented in many different way
(without having to write new custom skins).

Allowing multiple content objects to be built for different types of
reader (technical, novice, marketing, developer etc.)

Producing a static site that can be downloaded and installed on a users
machine.

(I'm sure there are more... )

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

Daisy + Forrest gives (3) now (see discussion on daisy dev list).

(4) is very nearly here, needs a little more work on the Daisy plugin
for Forrest, but it's not much (at least I don't believe so, I've not
thought long and hard about it)

(see my proposal
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111591833106339&w=2 ,
for another possible scenario)


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

(a) is for discussion either on the Daisy list or the Forrest list. I'd
be interested to hear your concerns, the plugin is merely
a whiteboard proof of concept so feedback is positively encouraged.

(b) is incorrect. You only need to maintain the site structure
separately if you want the structure to be separate. The current plugin
works this way because that is the use case I have - mixing content from
multiple input sources means it is impossible to use the Daisy
navigation editor. Besides I prefer *not* to use the Daisy navigation
editor as it is cumbersome since it is a web based system. I have a Drag
and Drop GUI editor (http://www.burrokeet.org ) that I use to maintain
site structure.

This allows the Daisy navigation to be optimised for content editors
rather than content readers.

It also allows multiple content objects to be designed from the various
sources. That is, different collections of documents targeted
at different readers (novice, developer, marketing, press etc.)

Having said all that, if required, it is trivial to make Forrest use the
Daisy defined navigation if that is what is needed. It merely requires
an XSL transformation of the Daisy navigation doc.

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

See my proposal yesterday,
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111591833106339&w=2

Ross

_______________________________________________
daisy mailing list
daisy@lists.cocoondev.org
http://lists.cocoondev.org/mailman/listinfo/daisy



Mime
View raw message