> > 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). > > > Sure, but not only that: probably you don't want your sitemap, > components and the like to be accessible from WebDAV: I for sure > wouldn't, for security reasons to say the least.
Well, I'm not so sure (could be my ignorance!). I suppose that sub-sitemaps solve concurrent access problems but here's what I'm curious to try. Instead of locking an entire site map or sub-sitemap to add a generator or transform to a particular resource, what if I could lock and update just a particular element top most <map:xxx> element or sub element. E.g. in the large sitemap included with the distribution, suppose I have 3 site developers who need to manage a portion of a live site, it'd be slick if you could simply lock a portion of the file /foo/sitemap.xmap//map:serializers[@name='wap'] [made up my own XPointer/XPath syntax there :-)] To me this means even more SoC and possibly even the capability to store the sitemap in an XML native store that allows XPath queries (and updates!!!). Then again, I suppose that CVS handles just this scenario by merging copies. Hmm. > > 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)? > > > Exactly. Probably impossible and wrong for sure. > > > > 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. > > > Take for granted that if you have writers they absolutely need the disk > drive metaphore and wouldn't settle for anything less. And yes, I think > that browsing is a must. What does the 'folder' metaphor looks like when you drill into an XML representation of Michael's headline/article store (or something more complicated)? What's the most granular item? What's the content type of each 'file' (needed to map it to an application, or do they all have file extensions)? What if that 'file' is itself an aggregation? Sorry, I still don't get this part but I'm eager to! :-) > > 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. > > > But this is the easy part! Take mod_dav, slide or the WebDAV servlet and > you're ready to go, you don't need any specific Cocoon support. Just > WebDAV-enable your cocoon webapp and try out Pollo > (http://pollo.sourceforge.net) as a starting point. It shouldn't be > difficult to integrate Pollo into, say, Netbeans, et voila' you have a > Cocoon IDE ready for your marketing guys ;) Ok. I'm with you but I think for large sites, more granular management could be needed. > > 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. > > > This is exactly my concern. I know that WebDAV is great and I want > WebDAV access to my content. The problem is where this support should be > placed. The strenght of Cocoon (unmatched by the other alternatives) is > the incredible flexibility and power that gives to you. I'm dreaming of > being able to specify sets of action to be undertaken when a document is > uploaded to the server (an example? commit it to a CVS server and make > that CVS my repository), or to map my security access rules (the > authorization or PMI part) directly in the Sitemap. And I'm wondering > about a perfect world where I can write my application filters so that I > can present the content to my writers in the format of their choice (I > was thinking about using Majix and JFor to allow for RTF editing of > simple XML documents). The problem is if Cocoon is the right > place for that. > > > > Which brings me to SoC. > > > > - the important separation of concern, IMHO, is end-user vs. > developer. I'm > > not as concerned with different developer roles > (presentation/coder). That > > might be because I really want Cocoon to rock for implementing > the 'two way > > web', not just the one way one. > > > Please define what you exactly mean for "end user" and "developer". > Where are content developers (i.e. writers) placed in your setup? I > understand that you're labeling them as "end users", and I don't agree > completely with you on that. You're right. I mean 'content developers'. I basically mean the guy at the browser, not the guy sitting with XMLSpy working on the sitemap. > > - within the 'developer' role, they need to edit #1-4 (the > sitemap, etc). > > > And there's no need for anything fancier that any plain WebDAV > environment for that. Or am I missing something? Note: there are RTs > floating around suggesting that in a production server the sitemap > should be compiled, i.e. not editable directly, and I basically agree > (with some concerns) to that. Gotcha. > > - within the 'end-user' role, they need to edit the pure > content. [Q: hmm, > > not necessarily true if they want to edit the presentation. Maybe impose > > this restriction?] > > > There might be XSLT writers that need to edit the presentation, but > again there's no need for WebDAV in Cocoon for that. Yep. > > - 'end-user's edit content through: web forms, document > processing (Word, > > OO), other apps, and on various devices (PDA, Web, application, > etc). [Q: > > isn't 95% of the use here though web forms?] > > > Web forms suck big time. This is the main concern: if you are a writer > and need to edit real world documents you can't stand the textarea > limitations. That's true. But there are lots of plug-ins for enhanced text areas. Also, I think you're getting very document centric. I think of Cocoon as a complete XML engine, it's not all text articles. Cocoon is great at managing structured content and that content is not easily edited without a form metaphor, either in the browser or in a form-or-XML-enabled app. > > > > To me it doesn't necessarily makes sense for Cocoon to manage the WebDAV > > access to the content. I can do it just as well or better using Slide in > > parallel, or from within my Cocoon actions using their CMS API. > > > This is exactly my point: I think we need to understand if it makes > sense to WebDAV enable Cocoon or if it's better to resort to other > already existing WebDAV environments. > > > > It does make sense to me for Cocoon to allow some WebDAV control of the > > sitemap, etc. If I could use Forte or FrontPage or XMLSpy or > some such to a > > portion of the sitemap, that'd rock. > > > But again, this can be done by any WebDAV application, there's no need > to extend Cocoon just for this. And I'm not that sure that I'd like to > give WebDAV access to my single point of failure (the sitemap). Not > before the sitemap becomes more robust (i.e. refusing to load an > incorrect sitemap). Ah. If you only had element by element locking and validation ;-) Per. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
