Gianugo Rabellino wrote: > 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.
You are using Cocoon in GUI applications ? No kidding ? GUI was the last place where I would have searched for applying Cocoon ;) > 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". I hope I understood you correctly; IOW, Cocoon perfectly produces and delivers content, but can hardly receive and decompose it. If we assume that we edited final dynamic and intermixed contents as a whole (e.g. a personalized corporate frontpage) via WebDAV, then I agree that reversing the production process is almost impossible to do. As I posted in my earlier response to Stefano, we have to target complete atomic contents instead, those informations that are being taken, transformed and intermixed. The URI space for standard web pages and WebDAV operation does not necessarily have to be the same, nor would it make sense. >> 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. It might be next to impossible to completely transform OO to DocBook or the other way around without loosing information at the moment, but I am confident we could do it at a lower level that DocBook; I haven't been able to check out DocBook or OO markup documentation. We have a multitude of options available regarding OpenOffice, including that we can ask for non-OpenOffice-markup to remain unaltered, or check out whether enabling DocBook in OpenOffice might be a future solution. > 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. I once wrote a perl app that took a sentence from command line and did this Babelfish round trip about ten times; the result was usable as a kind of party joke ;) > 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. Where would you differentiate between subprojects to belong to the CMS framework or Cocoon ? Best regards, Michael Hartle, Hartle & Klug GbR --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
