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 Fri, 02 Nov 2001 09:25:37 GMT
Stefano Mazzocchi wrote:

> Ok, let me jump into this since I already spent lots of brain cycles on
> this.

Same here :) I've been working for overe an year (and somehow still am) 
on those CMSish isssues, so it's a pleasure to jump in and see if we can 
find a viable solution.

First of all let me state my position: I'm currently _very_ skeptical 

about intermixing Cocoon and Webdav. I'm using Cocoon almost anywhere

(yes, in GUI application too, one of those days I'll send my RT about
this ;)), but in this case I kinda feel that Cocoon (or at least this 
version of Cocoon) wouldn't be the right tool for the job.

The main problem area lies in the Cocoon "one way" approach: Cocoon is 
great in "virtualizing" the URI space and decoupling resources from 
actual layout. It fails tremendously short the other way around: it's 
really difficult, given a "virtual path" to understand what are the 
resources that concur in producing the final result, and it's almost 
impossible, given a resource, to understand where it will be mounted 
(i.e. what will be the virtual URI that uses that resource). Cocoon 
looks to me as the crypt() functions: a perfect, robust and stable 
system with the feature or limitation of being almost totally "one way".

> Now what? XSLT is *NOT* (in general) reversible. Not even talking about
> aggregation, namespace reaction, dynamic XML expansion and so on. There
> is algorithmically no way that you can achive that.

Exactly. That is one of the problems.

> Ok, so we can presume the editors have a simple and standard interface
> for "authoring" content thru WebDAV. The editing tool will still be a
> problem (wait for my next RT for that) but if we define the contract
> thru WebDAV, we can, at least, separate the concerns and work parallely.

Sure thing. I wish it was that easy :)

> I see two possible solutions: direct and indirect. Direct means passing
> thru cocoon, indirect means bypassing Cocoon.
> 1) indirect: this is something that you can do even today with no need
> to write a single line of software. Create a virtual host (or another
> mount point, or another port on the server) that connects simply to the
> content documents that you want to serve.

This is, IMHO, still the only way to go. In a SoC enviroment it's the 
only solution that is capable of maintaing separate concerns, strong 
contracts and easy deployment. Yet there will be problems, we'll come to 
them in a short while.

> As far as dbXML gets under Apache, I plan to work on something
> equivalent for this database as well, hopefully getting it integrated
> with the database core in order to obtain stuff like versioning and
> resource metadata directly from the database.

Looks great, I proposed that some time ago to the dbXML guys, even if my 
approach was to write an JDNI provider so that it would have been 
possible to use WebDAV (the Tomcat webdav servlet relies on JNDI) and 
much more.

> One feature I'd love, would be to cover some webdav folders with
> automatic validation: 

Absolutely great, again there is some discussion about this feature in 
the XML:DB lists (collection-based schema validation), even though, of 
course, there are pros and cons.

> 2) direct: this requires webdav support built into Cocoon.
>  http://host/path/file.content
> and we obtain the content view of the resource.

Again: I wish it was that easy. AFAIK, though, this is to say the least 
a very difficult result to achieve. Start by defining "content" in 
Cocoon internal terms: the first definition that comes to my mind is 
"generator output", but this is _not_ always true, and it would probably 
  be even less true in complex environments. Think about Xinclude. Think 
about XSP, x:forge, DXML or any other dynamic XML generation framework: 
in the generator stage you might not have the actual content but only 
directives to generate it.

Of course it is possible to state a contract such as those directives 
must be bidirectional: this means not only that when I ask for content 
the directives are processed and the actual content (as it comes out 
from the whole process) is served (this is the easy part) but also that 
when I put the modified content back to Cocoon those dynamically 
generated part must be taken into account and updated wherever they are. 
Tricky, to say the least.

>  b) create webdav applications.
> Now, this is an entirely new concept but potentially explosive: we
> normally talk about "publishing" when the GET action is mainly in use,
> then "web application" when both GET and POST are extensively used. Now
> I coin the term "webdav applications" for particular web applications
> when the full range of webdav http headers is used by the user agent.

Again, looks great, but I fail to see whether this is feasible or it's 
pure rocket science. I'm skeptical but please try to convince me: I want 
to be able to see the moment where I will be able to say "Beam me up 
Scotty" and have it happen :)

> Well, anyway, something is for sure: the future of web authoring is
> webdav and Cocoon must follow that trend or won't be used in places
> where it would really kick ass.

Agreed, but beware of the "flexibility sindrome". :)

One word about OpenOffice: since they announced that they were going to 
use XML as their native format I've been very excited about it. When I 
saw the first .sxw file and understood that it was a jar file with a 
clean and elegant separation of the needed components and a clever and 
well designed vocabulary I thought we were finally there and I started 
dreaming of a bunch of XSLT and Cocoon components to be able to deal 
directly with OO files.

Unfortunately I understood that this is not an easy task. The XML format 
they are using has little knowledge about structure as it's heavily 
oriented towards presentation aspects: it's almost impossible to go 
from, say, an OO file to DocBook without having to do some hard 
guessing. The situation is even worse the other way around: given an 
editing cycle of creation and subsequent modifications I expect the 
quality to degrade even more.

If you don't know what I mean just go to Babelfish (or any other 
automatic translation engine), ask it to translate a phrase and use its 
own output as an input for a backward translation. Do this "round trip" 
translation for a couple of times and see the result. This is exactly 
what I fear would happen to our beloved content.

The only viable (and general) solution that I see now is to use directly 
the OO files as the content itself, but this adds little or no value to 
the ability of being able to transparently edit content.

While we're at it, I'd like to add a point in favor of using Cocoon and 
WebDAV: clients are stupid, and you have to present them the content in 
their own format. Now suppose that you have a mixed environment, where 
someone is using MS Word, others are using OpenOffice and others are 
hand-editing the raw XML: what you want to do, given that you would be 
using some "web folders" like setup, where a WebDAV server appears to 
you just as a remote disk, is to present your writers with different set 
of resources: you want on their virtual drive to appear for the "news" 
content three different resources such as "news.doc", "news.sxw", 
"news.xml". You might also want to provide a CSS file for editing with 
CSS enabled XML editors (Merlot as an example), and of course you also 
want the content to be locked and versioned indipendently from the 
actual resource being used (so that if someone is modyfing "news.xml" 
even "news.doc" would be locked). In this case yes, Cocoon would rock, 
but I'd rather see a CMS (or, even better, a CMS framework) written from 
scratch *using* Cocoon that generally enabling any Cocoon to 
transparently edit content.

Anyway, let's keep it rolling: I'm confident that we will come out with 
something good, as this is what always happened here. :)


Gianugo Rabellino

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

View raw message