cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <>
Subject Re: Serving static XML files a la Cocoon-1
Date Thu, 25 Apr 2002 20:26:04 GMT
From: "Peter Flynn" <>

> > > >did this fine: why break a perfectly good piece of software?
> >
> > That "perfectly good piece of software" was broken, and was not able =
> > to
> > fulfill Cocoon's aim, that is mainly Separation of Concerns.
> Hardly "broken" but there was nothing in Cocoon 1 about separation of
> concerns, only about serving XML with XSL[T]. This phrase seems to
> have arisen since.

The Cocoon1 front page:

The Cocoon project aims to change the way web information is created,
rendered and served. The new Cocoon paradigm is based on the fact that
document content, style and logic are often created by different individuals
or working groups. Cocoon aims for a complete separation of the three
layers, allowing the three layers to be independently designed, created and
managed, reducing management overhead, increasing work reuse and reducing
time to market.

"separation of the three layers" and "separation of concerns" is the same

If a program fails to fulfill it's goal, it's broken.

> > It puts in a page (content) something that tells what to do with the =
> > page,
> > which has *nothing* to do with the content of the page itself.
> You mean the xml-stylesheet PI. Yes, except that it's a convenient
> place to put it, avoiding the need for a catalog (which it seems is
> all that sitemap.xml is). Using entityrc and catalog files was always
> a pain when serving SGML with stylesheets.

Putting SQL statements in JAva classes is convenient too, but hardly easy to

It seems that you are more into an Object oriented view, while Cocoon2,
which uses Avalon, is more Component Centric.

> > But if you think that a page has to have all that is needed to render=
> >  it,
> > there is no separation, of course ;-)
> It is poor document engineering to omit that information from the
> instance, in the same way that it is poor practice to omit the
> Document Type Declaration, because it means someone coming to the
> document from the outside requires exogenous information. But you
> certainly don't have to use it from that location if you prefer a
> catalog-based approach. In other words, separation of concerns is
> fine, but not at the expense of usability.
> > Cocoon1 separated Content and Style, but failed totally in separating
> > Administration and Flow from the first two.
> Not the way I implemented it, but that's history.

If you put PIs in the document, it's a failure.

> > Cocoon2 separates Administration and programming quite well, and Coco=
> > on2.1
> > will separate Flow as well (there is a schecoon in scratchpad that al=
> > ready
> > works).
> OK. Not needed at present, but nice to know.
> > If you think that all this is too complicated or theorical,
> No, it's fine, just the transition seems to be undocumented.

Unfortunately you are right on this.

> Thanks for your help: this is looking marginally better, but some
> proper documentation for upgrading would have been useful. If I can
> get it to work, I'll certainly write it.

I hope so :-)

Nicola Ken Barozzi         
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)

Please check that your question has not already been answered in the
FAQ before posting. <>

To unsubscribe, e-mail: <>
For additional commands, e-mail: <>

View raw message