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. :) Ciao, -- Gianugo Rabellino --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
