Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3BE2F03F.7060500@rabellino.it>
Date: Fri, 02 Nov 2001 20:13:03 +0100
From: Gianugo Rabellino <gianugo@rabellino.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.5) Gecko/20011011
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Integrating Cocoon with WebDAV
References: <NDBBIKLOLMEELKELLPFIOELFEHAA.per@onclave.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

> Having thought much about this issue also, I'd like to add my $0.02.
> 
> IMO, the categories of Cocoon 'components' that are of interest to manage
> via WebDAV:
> 1. the sitemap file itself
> 2. specific elements within the sitemap (e.g. edit just the matchers in
> sitemap)
> 3. any subsitemaps
> 4. the 'code' referenced by the sitemap (e.g. Java generators, actions,
> XSLT, etc).
> 5. the content used or aggregated by the sitemap.
> 6. the final output
> 
> [Q: What did I miss?]


I'd say this is it. Better: this is way too much :)


> 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.

> 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.


> 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 ;)

> 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.


> - 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.

> - 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.

> - '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.


> 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).

Ciao,

-- 
Gianugo Rabellino


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org