cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hartle <>
Subject Re: [RT] Integrating Cocoon with WebDAV
Date Sun, 04 Nov 2001 13:14:13 GMT
Stefano Mazzocchi wrote:

>One proposed solution (Michael's), is to use
> CMS -> Cocoon
> edit agent -> OpenOffice
>which has several PROs and several CONs.
> 1) much is already written (which is not bad :)
> 2) fully portable
> 3) fully open source
> 1) OpenOffice XML format is ultimately useless being nothing semantic
>but ultimately presentation driven. I has more or less the same semantic
>content that M$ Word spitting HTML and Gianugo is perfectly right when
>he says that do it back/forward a few times and you're screwed.
This requires us to design the transformation from our content xml 
format (like DocBook, which you prefer) to OpenOffice and back in a way 
that this will not happen. The consequence of this might be that we 
cannot "map and reverse" each element and attribute, but we definitely 
get the most out of it.

Matt Sergeant 
has shown a way from OO to DocBook that may not be perfect, but a start; 
he also makes some good points on requirements that clients tend to make.

>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.
Millions of users are accustumed to Office environments and the 
resulting non-semantical approach to work. Blame it on Microsoft or 
someone else, but there are hundreds of thousands of users who still use 
tabs where tables would be appropriate. I recently had a meeting where 
it took more than 10 minutes to make others understand the difference 
between semantic and non-semantic.

The problem is not whether or not this may be a dead end in the very 
long run (which I do not believe and even in case, I then would describe 
it as viable legacy support), but what a solution requires, what users 
are accustomed to and what they are willing to accept. I made the 
experience the hard way that the latter two are critical, and with 
corporate players that are affraid of radical changes to semantic 
approaches, this will stay this way some time.

>2) Some might think that the "arrow of time" of the cocoon pipelines
>are inherently biased outward (I don't believe so, but anyway) and
>adding webdav capabilities might ruin the elegant internal design.
>Personally, I think that once the flowmap is in place and we have a
>better way to indicate flow between resources and between different HTTP
>actions on the same resource, then most problems will be cleared even on
>this side, but for now things remain.
I came to the result that to protect the investment in current component 
categories like Generators and Serializers is the best choice available 
at the moment, as they will still be around when flowmaps are available 
(hopefully I understood it right and thats the case)

>1) CMS because Cocoon shouldn't implement CMS stuff but should simply
>"use it". Things like user management, locking, revisioning, metadata,
>scheduling and all that should be a layer built around the storage. The
>contract between CMS and cocoon being some API or some avalon behavioral
I like this part definitely; it matches my understanding and vision of 
Cocoon as a representation layer for things like Batik, FOP and CMSs.

>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, they would be anyway: in fact, when they approach an editing
>system, they don't ask the question "where", but "what". The translation
>between "what content to modify" and "where to save it", mixes concerns.
>Result: the disk metaphore (so well used into almost all operating
>systems, but *NOT* the web!) forces editors to know where to place
>things and they don't care. (many thanks to Laura, my girlfriend, for
>opening my eyes on this!)
I really do not believe that is the case. Perhaps an editor who just 
creates or edits contents once in a while may show no interest in the 
way contents are organized (the "where"), but the majority of editors is 
working regularly on certain areas that they are assigned to, and they 
will definitely participate in the way content is organized.

The disk metaphore instead gives a fast start and "forces" editors to 
know what they create and edit; making the appearing(!) disk layout for 
each editor customizable gives him/her the opportunity to modify his 
view(!) according to his preference and work style. The central storage 
in a CMS, for example, is not affected by this.

That is what Cocoon is about in my eyes; transforming content to deliver 
certain views on content. What a user sees when looking into a WebDAV 
folder strongly reminds me of such a view. When a user loads and saves 
content from a WebDAV folder, he is interacting with such a view like a 
person using a form on a web page. I do not talk about turning Cocoon 
into a CMS, but to enable Cocoon to provide views to a new, interactive 
component like a CMS. Adaptors to various CMSs would just be another 
brick in the wall like Batik or FOP; Cocoon does not produce PDFs or 
JPGs itself, but it hands through the task.

I do not believe that directly integrating a CMS into Cocoon itself is a 
good and healthy thing, as it removes choices of combination. But Cocoon 
works perfectly as a layer to map requests to virtual/real resources 
that may have needed some transformation, and I want that power to 
assist me when I target WebDAV usage.

>So, what would be the best editing system for a content writer?
>Log into the editing virtual host, ask what content to add, modify,
>approve, change, schedule, and what not and have the CMS give you a page
>that allows you to "edit" it in place.
>How so? A XUL-powered mozilla IDE that integrates skeleton-based
>in-place editing capabilities.
If I understood the skeleton-based in-place editing capabilities 
correctly, it goes into the direction of forms, textfields and the like. 
One thing is for sure, writers hate writing content in a solely 
skeleton-based environment as it gives you absolutely no chance of 
semantical flow-text attributation (something that can yet be achieved 
in the OpenOffice direction in the future). I saw products that tried to 
solve this problem in a skeleton-based manner and failed in the eyes of 
users. Something writers will hate, too, is that you do not have the 
support of spell-checkers, file import/export filters and the like, 
which are available in either OO or Suns extended StarOffice.

>What is that? Ok, assume you have a news item like this:
> <news title="...">
>  <picture href="..."/>
>  <text>
>   <p>sdfljskdfj<strong>lskdjflk</strong></p>
>  </text>
> </news>
>then we can get the schema of this and transform it into a markup that
>indicates the structure but also the visual information required for a
>client to present a "semantically-WYSIWYG" interface.
>So, Mozilla is my choice, but it could also be implemented as a java
>applet, or java application that reads this information, prepares the
>skeleton, fills with existing content and guides your editing
>Then it saves using WebDAV.
>I think mozilla could allow us to use all the CSS capabilities to
>implement easily the skeleton and graphic placement, and also be
>completely portable across systems. (yes, editors will be forced to use
>Mozilla, but I see nothing wrong in that :) nor a limitation of their
>In short, such yet-to-be-written "Structure Skeleton Description
>Language" (SSDL) should be the driver of the editing experience and the
I do not have a good feeling regarding this approach; there is already 
an inflation of (.*)(D|L)L languages around.
What about the pure XML/CSS approach where there are already usable 
standards and open source implementations ? (Batik contains a CSS 
parser). This would allow semantic attributes in a WYSIWYG environment, 
but it would still lack the infrastructure an Office implementation 
could provide.

If you are willing to walk this far into the direction of pure 
semantically-WYSIWYG to bring it to a public success, why not develop 
import/export filters or similar OO components ? You would benefit from 
an established infrastructure and adding it into a well known product 
where you do not have to do all the documentation and training for 
yourself when it is being used by a client. (,

Best regards,

Michael Hartle,
Hartle & Klug GbR

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

View raw message