cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Integrating Cocoon with WebDAV
Date Tue, 06 Nov 2001 11:08:46 GMT
Per Kreipke wrote:
> > > > Again, I think WebDAV access through Cocoon is more than worth the
> > > > effort.
> > >
> > > Definitely worth having, not clear how :-)
> >
> > Uh, what a thread :)
> >
> > Ok, let's try to summarize a little.
> >
> > This is what I believe is a good chain for publishing:
> >
> >  user agent <- publishing <- store <- CMS <- edit agent
> I agree with Gianugo that the CMS should hide the store:
> user agent <- publishing <- CMS <- edit agent
>                               |
>                             store

Yes, good point. This is definately easier to componentize.

> > which is a native XML DB. IMO, it lacks a few features to turn it into
> > such a storage system (most notably, versioning, locking and a few other
> > things that things like CVS has), but it's a great place to start and a
> > great way for the publishing system to have access to the content (thru
> > XQL or the like).
> One thing I'm not thrilled about with dbXML is that it's document centric
> [my opinion may be out of date, I'm not sure], it's hard to query across XML
> documents.

Look: XIndice is not dbXML moved to Apache, it's a new project "seeded"
with the current dbXML implementation so that users can take a look at
it and shape the further direction of the project.

So, I totally agree that document-centric view sucks. IMO, a native XML
DB should be seen as ONE BIG XML DOCUMENT and then you have an XQL
frontend to query information and a WebDAV mapping backend so that
people can know if an element should be considered part of a directory
or part of a file.

(this can easily be achieved with some namespaces attribute on an
element that states that it is a root element for a document)

But this is a talk for the XIndice mail list (when it will show up).
> >  user agent <-(http)- cocoon <-(xql)- xindice <-(?)- ? <-(webdav)- ?
> > which leaves three big question marks.
> > The unknown contract will probably be filled by the xindice guys (XMLDB
> > API being the probably candidate, but maybe a JSR would add that
> > functionality into JDBC4, I don't know at this point, but I'm confident
> > that something will come out as soon as the xindice people (with us)
> > tackle the problem in detail).
> Ok, so given that we eventually define all the contracts, why do we need to
> choose the implementations? I think that, in the J2EE vein, being able to
> choose my own implementation for
> 'standard services' is a great one.
> Isn't it ok to define the missing contract but leave the implementations as
> '?'.

Yep, it is. But around here, it's good to provide both so that you
actually have something that works and don't have to way years for the
JCP to approuve your proposal, get the spec out and then buy WebSphere
15.0 that implements it.  :)
> >  1) CMS because Cocoon shouldn't implement CMS stuff but should simply
> > "use it". Things like user management, locking, revisioning, metadata,
> > scheduling and all that should be a layer built around the storage. The
> > contract between CMS and cocoon being some API or some avalon behavioral
> > services.
> Great!
> > At the same time, content editors don't give a shit about "where"
> > resources are located and I disagree vehemently with Gianugo when he
> > says that you have to give them the harddisk methaphor otherwise they
> > are screwed.
> >
> > Well, they would be anyway: in fact, when they approach an editing
> > system, they don't ask the question "where", but "what". The translation
> > between "what content to modify" and "where to save it", mixes concerns.
> Based on some exerience, I agree with you Stefano. One example, newspaper
> editors deal with departments, 'beats', teams, campaigns, what have you,
> many of which cross over. Their organization certainly doesn't have to be
> hierarchical. And newspaper writers are very accustomed to filing stories
> from far away without a 'desktop' metaphor at all. In fact, they're so
> _extremely_ time sensitive (down to beating other competing outlets by
> seconds with a news story), they rarely use cumbersome, slow, generic word
> processors, they use highly customized apps.

Bingo!! exactly. I'm trying to cover exactly those use cases where
people what to focus on their job (writing content) rather than figuring
out where to save it in order not to break the system!
> > How so? A XUL-powered mozilla IDE that integrates skeleton-based
> > in-place editing capabilities.
> I don't understand. Why not just say 'XUL for in-place editing'? Why does it
> have to be mozilla based?

Good point. :)

You're right: "xul for in-place editing", then Mozilla is just one of
the possible implementations.

Note: XUL is proprietary, but can you say that something is proprietary
if it's done by an open source project? IE HTML is, in fact, more
proprietary than XUL from that point of view, even if it's a well known
> > So, should webdav be integrated into Cocoon? well, at this point, it's
> > early to tell and it depends on the shape that the CMS part will take.
> >
> > One thing in my mind is for sure: Cocoon shouldn't become a CMS, but
> > might well adapt the CMS API with the XUL-powered solution and, in that
> > case, it might require some WebDAV capabilities of some sort.
> Ah, there it is without any choices about what CMS or editor I have to tie
> myself to :-)

Exactly: webdav can allow all usage editing solutions to cohexist.
Wouldn't this be great?

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message