cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Forrest and the NDS (Re: [RT] Moving towards a new documentation system)
Date Sun, 12 Oct 2003 10:40:39 GMT

On Sunday, Oct 12, 2003, at 04:23 Europe/Rome, Jeff Turner wrote:

> On Sat, Oct 11, 2003 at 03:17:48PM +0200, Stefano Mazzocchi wrote:
>>
>> On Saturday, Oct 11, 2003, at 14:25 Europe/Rome, Nicola Ken Barozzi
>> wrote:
>>
>>> Please don't forget Forrest.
>>
>> we are not.
>
> :)  Let's remember that there's hard reuse and soft reuse.  Hard reuse
> means physically integrating with Forrest/Lenya.  Soft reuse means
> reusing ideas, people, and code where appropriate.  For a new project 
> in
> RT phase, worrying about hard reuse with Forrest and Lenya would IMHO
> just slow things down.

I agree: try to come up with a system that runs first and *after* try 
to merge the results and possible changes back in the original systems. 
This reduces the potential community friction when changes require some 
little paradigm shifts.

> Forrest started with a RT, a mailing list, and a bunch of Cocooners
> willing to contribute.  I wasn't at the GetTogether.  I've never seen a
> RT articulating the vision for this project.  There's just tantalising
> snippets.  Could we perhaps dream up a name ('linotype' seems obvious),
> start a mailing list, and have some RTs on what this is all about? :)

That's what we are trying to do with this thread, Jeff, get a name, a 
collection of random thoughts and get going. I don't think we need a 
different list for now.

The things that were discussed at the hackaton were simply 
higher-bandwidth version of this conversation. And Bertrand started it 
over in order for everybody to know what were talked about and having 
the ability to jump in and help.

In case something is not clear, I'll be very happy to explain it.

>> I thought about it and I totally resonate with Bertrand: we need to
>> outline an incremental transition to our own CMS reusing as much dog
>> food as possible (which is also good for a community perspective).
>>
>> Here is my proposal:
>>
>>  1) the system gets divided into three parts
>>
>>      - frontend -> mapped to http://cocoon.apache.org -> static
>>      - repository -> a WebDAV server
>>      - backend -> mapped to http://edit.cocoon.apache.org -> dynamic
>
> The mozilla.org site does something similar, in that the 'edit this 
> page'
> link goes to:
>
> http://doctor.mozilla.org/?file=mozilla-org//html/index.html
>
> I've long thought this would be a great Forrest enhancement.

exactly. Zope does similar things as well.

It's been 3 years I wanted to implement this in cocoon 
(frontend/repository/backend architecture)... the incubation of lenya 
was instrumenting for this. also the creation of linotype 
(experimenting with serious editing, repository separation and 
numberical URIs).

the wiki forced me to realize it's now time to move on and the hackaton 
gave me a way to express myself clear enough so that others were 
tickled by it.

>> The future idea is to use indirect linking where lookup is a sort of
>> "what's related" understood out of the analysis of user patterns, but
>> this is far ahead in the future.
>>
>> For now, I think direct linking would be enough for our needs... we
>> just need a good "lookup and discovery" of learning objects integrated
>> in the backend.
>>
>>                                   - o -
>>
>> As the implementation
>>
>>  1) forrest will be used to generate the site from the contents of the
>> repository
>>
>>  2) the repository can be either plain vanilla subversion or a webdav
>> server implemented by cocoon on top of another repository (either
>> subversion or catacomb or JSR170). even CVS, but we might want to stay
>> away from it.
>>
>>  3) lenya will be used as the backend.
>>
>> Missing things:
>>
>>  1) is forrest already capable of doing what we ask?
>
> Possibly.  Forrest's sitemap is built in layers:
>
> cocoon://**.xml         # Source pipelines generating doc-v12
> cocoon://body-*.html
> cocoon://menu-*.html
> cocoon://tabs-*.html    # Intermediate formats
> cocoon://**.{html,pdf}  # Destination formats
>
> So just switch in a different **.xml subsitemap, and Forrest will build
> the site from whatever backend you choose.

Sounds perfect.

> Forrest's indirect linking system is (IMHO:) pretty cool and Wiki-like,
> in that I can write <a href="site:foo"> from anywhere, and it links to
> the 'foo' page wherever (or whatever) it is.  The source files have a 
> URI
> space all of their own, independent of the final http: URI space.

Very good as well.

> The linking implementation is very flexible, built in input modules.  
> <a
> href="site:index"> causes the 'site' InputModule to be fetched and 
> passed
> the 'index' key.  A SimpleMappingModule converts this to
> '/site//index/@href', which is fed to an XMLModule, which interprets it
> as an XPath into the navigation file, site.xml.  As the XPath prefix 
> and
> suffix are configured in cocoon.xconf, any XML format for the 'linkmap'
> (aka site.xml) can be used.  Lots of gory details at
> http://xml.apache.org/forrest/linking.html

As you can see from my question, I (and possibly many others here) lost 
contact with forrest a while ago: you people simply did the job well 
enough for us crawl back in our corner as simple users ;-)

but as you suggest, we might need "soft reuse" at this point, so you'll 
hear from us when things don't work (or you are more than welcome to 
join, of course).

>>  2) what's the best repository? where do we install it?
>>
>>  3) is lenya enough for what we need? (Michi says so)
>>
>>  4) how much work is the integration of linotype with lenya? (I'll
>> investigate this soon)
>>
>>  5) how do we get the wiki into the repository? (I plan to write a
>> wiki-syntax editing pane for linotype, would this be enough?)
>
> Could use the Chaperon Wiki grammar to convert to XML, but..
> grammar-based validation results in really undecipherable error 
> messages.
> Might be best to first use a regular Wiki engine as a 'lexer', to get 
> the
> Wiki syntax 'well-formed', and then use a grammar to go from 
> well-formed
> Wiki -> XML, and then use an XML schema to ensure validity.  3-phase
> validation of Wiki syntax.  Could warrant a project all on its own..

yeah

>>  6) how do we get the rest of the data into the repository?
>>
>>  7) how do we make it simple to edit linkmaps? what searching and
>> proximity tools can we provide for this?
>
> Lenya is probably the best hunting-ground for this.

yep, forrest as the frontend engine, lenya as the backend engine, 
cocoon empowering both, documents all safely stored in one repository 
(no more CVS branching for docs!!), easy editing, easy workflow, 
ability to assemble trails of documentation, no need to bug 
infrastructure@ for a dynamic site, mirror friendly...

... gosh, seems like heaven ;-)

--
Stefano.


Mime
View raw message