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. >presentation/content)? > 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 "vnd.sun.star.webdav://". 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. >Observations/Questions: > >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 >this. > >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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
