cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: [RT] Integrating Cocoon with WebDAV
Date Sat, 03 Nov 2001 21:56:03 GMT
Stefano Mazzocchi wrote:

> This is what I believe is a good chain for publishing:
>  user agent <- publishing <- store <- CMS <- edit agent

Almost agreed, but not totally. IMHO a better approach is:

user agent <- publishing <- CMS <- edit agent

The publishing engine should never pull content straight from the store, 
  it should rely on the CMS (the only one who knows about rules, 
permissions, schedules and so on). But this is a minor issue, even if it 
introduces a new contract to be defined between the CMS and the 
publishing part. I'd suggest that a (pseudo-?)protocol is the best way 
to go here.

> The second one is more tricky and not everyone agrees with that but I
> think it's a good move:
>  store -> XIndice (formely known as dbXML)

+1 or better yet: *any* XML:DB compliant database. Note: I kinda 
consider this a good compromise, since I'd better think that the CMS 
should be "store agnostic" as much as possible, but yes, this can be a 
good start.

> If you want my personal opinion: this is a dead end. OpenOffice (just
> like office!) suffers from WYSIWYG syndrome and it's inherently useless.
> It sucks that so many millions of lines of good code are nothing useful
> for us, but hey, this is so for many other things, so no biggy.

Unfortunately true. :(

>  2) Some might think that the "arrow of time" of the cocoon pipelines
> are inherently biased outward (I don't believe so, but anyway)

Neither do I, but given the current status it might turn out to be 
confusing to say the least.

>  3) CMS provide a bunch of things that Cocoon doesn't currently provide
> and that must be implemented, but then, it would either have to rely on
> an external client, or provide a webapp that copes with those things.

Now the CMS part will be the trickiest one. I'm still convinced that it 
can be done *with* Cocoon, but it shouldn't be done *by* Cocoon. Well... 
I'm a Unix guy, I feel better with small cooperating systems, each one 
performing very well one or two simple tasks. I fear a lot the 
monolithic approach, so I would exercise caution before entering the 
application domain within Cocoon itself. Anyway yes, it doesn't really 
matter at this stage.

> At the same time, content editors don't give a shit about "where"
> resources are located and I disagree vehemently with Gianugo when he
> says that you have to give them the harddisk methaphor otherwise they
> are screwed.

Well... this is what they used to IRL. I'm all for studying new 
approaches, but we shouldn't forget about editors and their computer 
knowledge. Not to mention that the "in-place" editing (be it via Mozilla 
or not)  that you're suggesting has for sure a lot of PROs, but also a 
lot of CONs, the first being the inability to operate in disconnected 
mode, with user interface problems (I've seen so many web page editors, 
even if I confess that I miss the power of Mozilla) coming as a good 
second: wait until your writers will ask you for spelling checkers to 
understand that you're in a dead end alley.

I'm still convinced that a writer knows about a word processor, this 
being its instrument of choice. Of course she can learn to use another 
metaphore, but this (which comes from real life experience) scares the 
hell out of me. Anyone who tried to convince a team of writers to switch 
  from Word to Staroffice probably shares this feeling with me. I'd 
rather keep the word processor metaphore whenever possible: not that I 
like it, but they do.

> In short, such yet-to-be-written "Structure Skeleton Description
> Language" (SSDL) should be the driver of the editing experience and the
> client should be able to get a document, its schema and its associated
> SSDL skeleton and return a valid document, but allowing the editor to
> work in a "semantic WYSIWYG" experience.

Has anyone worked with the new (commercial) XML Spy web module? It seems 
to do almost exactly what you're envisioning.

> Of course, the cons of this is that all the software has to be written
> and the SSDL language needs to be defined, but, hell, I'd like to code
> on a solution that lasts, rather than writing gluecode around hacks in
> order to avoid some more coding and end up throwing everything away in
> the future.

Enthusiastically +1 here, please enlighten the path and I'll follow you. :)


Gianugo Rabellino

To unsubscribe, e-mail:
For additional commands, email:

View raw message