> 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.
Sure. Unfortunately, you're asking me to adopt your UI methodology for my site :-). I'm assuming that'll be customizable. And how will we indicate the scope of the editable object if there are nested ones on the page? Since the structure of the content doesn't have to match the structure of the presentation, I'm not sure what gets an edit button or scope rectangle. In your example, I can imagine value added services changing the article for presentation (HREF on ticker symbols, list of related articles below the headline, etc). Does the edit button appear everywhere? If I click edit an article that encloses other content, do I end up editing that too? I was suggesting instead of indicating the atomic units in the browser during 'reading', that during 'editing' Cocoon returns the content view of the data, without the presentation layer (or perhaps with a reduced version or application specific one). XPath/XPointer could even be used to return portions of the content for editing and locking. Sure I'd love Cocoon to have a pluggable architecture for XMLSchema based editors, even though I'm still not convinced that the presentation lends itself to displaying edit buttons next to each editable piece. I think a precursor to that is having a WebDAV enabled content store that can address portions of the aggregated content. But I don't get why Cocoon should expend the resources to develop it when it seems to me it'll need to be in parallel to the sitemap and there are other existing solutions. I think we're very close to saying the same thing but I'm in favor of putting some more of the burden on the application. Perhaps Cocoon could simply tag editable sections units to the editing application (using a new XHTML subset). Word understands fields, sections, chapters, locked sections, etc. > 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. Doesn't this require work on the user's part to register the application? I thought Content-Type was the way to switch applications? Shouldn't it really be based on the schema of the content being edited? > 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. Exactly. > 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. My problem with imposing a tree hierarchy on the content storage is that security is hard to implement if the content is reused in different contexts. That is, what if your article appears in two places? Which WebDAV based URL defines the security on that object? /home/article.html [article content is featured here] /per/articles/article.html [but really lives here] Which security settings get used? What do you see when you browse /home/article.html? [Q: does WebDAV allow aliasing and does it follow them during access?] > > >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. Definitely worth having, not clear how :-) Per. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
