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 Fri, 02 Nov 2001 18:17:11 GMT
Per Kreipke wrote:

>Very simple summary of thread so far:
>a. what Stefano, Michael, Gianugo, Ulrich agree on is that handling #1-4
>(sitemap) is different from #5 (the content).
>b. it'd be extremely hard to edit #6 (the output): reversing the
>transformations, then decomposing it into its constituent pieces using the
>'reverse pipeline' discussed in this thread. How it even work when the same
>document is available in PDF, WML, HTML, XML, on different devices, etc? As
>stated by others: does it even have meaning to edit a transformed document
>because it implies that the author is crossing concerns (e.g.
There is a difference between the browsable web site and the atomic 
content unit that this website contains. We cannot reverse the 
transformations that Cocoon made to generate a particular web page in 
order to retrieve the atomic content unit that make it up, so we have to 
concentrate on using WebDAV on loading and saving those units. Let's 
make an example where I can show how we can address this topic fairly easy:

We have a intranet web page of a company here; on the right side, there 
are several current news articles, each just showing the news title and 
a one line summary, while the news title is a link to a page showing the 
whole article. On the center, we see the full-blown detailed news 
article. Loading and saving this whole web page directly via WebDAV does 
not make sense, as we cannot propagate changes back into the appropriate 
places correctly.

Instead of editing the full page, I logon to the site. As a consequence, 
the web page is now being rendered with a additional links next to each 
atomic content unit. On the right side, next to each news article 
summary, and on the center, next to the title of the full-blown news 
article, there are links called "edit", each referring to a seperate 
WebDAV-URI from where this atomic content unit can be loaded and saved 
to in a format which is suitable for editing, eg OO or Word. I click on 
the link, with the protocol being registered to the editing application. 
For OO and WebDAV, this would be "". As a 
consequence, OO opens, loads the content and presents it in an end-user 
compatible way. We modify the content to our needs and simply save it back.

As Cocoon allows transforming XML content to a multitude of formats 
(PDF, RTF, PS), stacking WebDAV support ON Cocoon gives many interesting 
opportunities. Speaking in Cocoon terms, we could add Serializers for OO 
(my favourite) to deliver OO files and write a Generator (Deserializer) 
to retrieve back the content, to allow the following:

1.) We can load and save contents, allowing additional steps like 
workflow operations to be interwoven.
2.) We can browse and load dynamic virtual contents; any application 
that might benefit from concepts like virtual harddisks (eg. Explorer 
namespace extension) can now do so in a server-based manner easily.

>i. is 'web folders' access to #1-6 necessary (e.g. does it need to be
>browsable)? We could just use WebDAV to do resource locking, searching,
>versioning, etc without browsing.
I am against leaving browsability behind; a solution should be able to 
cope with WebDAV completely.

>ii. corollary: perhaps not all methods of WebDAV need to be supported.
>iii. WebDAV access to #1-4 (sitemap) would be interesting and would require
>integration with Cocoon. I can't wait to see a Cocoon aware IDE based on
>iv. WebDAV access to #5 (content) shouldn't require access through Cocoon,
>it could integrate directly to the XML content (dbXML, etc). This is the
>'atomic' stuff Stefano, et al mentioned (I think). Con: it would require a
>separate URL space independent of the sitemap controlled space.
Again, I think WebDAV access through Cocoon is more than worth the effort.

Best regards,

Michael Hartle,
Hartle & Klug GbR

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

View raw message