cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject [long] cocoon digital archeology
Date Sun, 11 May 2003 04:27:38 GMT
slow day today in Quito, Ecuador. so I decided to do something that I
needed to do since, at least, a few years back: datamining my email!

So, dig and dig, I found an mbox of the *first* cocoon mail list: That list was hosted by Jon Stevens on his
own machine back in the days where was a "sister
project" and the Apache Group server (the ASF was being created) was
still httpd-only.

Jon lost the backup tapes of those machines, but I found my old
Netscape4 directory backed-up and so, here it is, some history.

This is the first time I mention publicly the existance of Cocoon, Tue
Jan 26 20:48:07 1999 on

------------------------------- cut here -------------------------------

Subject: Re: FW: Persistent object store
andfaulttoleranceprotocols[was:Re:Back    online!]

lichtner wrote:
> > > Maybe someone on this list could give us a pointer
> > > on how to start a GPL project for that? Then we
> > > can make a new mailing list (and get off this one)
> > > and start designing.
> >
> > Hoping that you're not sarcastic, if you are interested drop me a note.
> Totally serious, but we need a starting point.
> I bet you'd like to take a stab at the design :)
> If so, in the meantime i could read the EJB spec ...
> I can put about 10 hrs a week, maybe more, especially
> if it gets interesting.
> We can get space for a web site for ~$50/month, or
> we could as someone to host the cvs tree for the project.
> Again, I have never set up web cvs ...

Hey, you guys, wait a second!

We are talking about many different things in this thread so I guess we
should settle it down at once.

1) EJB Server: I don't really know what it means, but I may have HUGE
political implications in the future directions of this project. I
really would like some of you to make up a nice proposal to create
another project for Java Apache following this directions. You have
blank paper on this: make your minds going and we'll decide if it needs
further investigation or if it's enough to start a new project.

2) Better Distributed Behavior of JServ: I don't know what this means
either. I'm so confused about all this, that I think we all missed the
big point. What Jserv needs for the future.

3) Deciding what to do and where: we were talking about many different
things at once. We should focus on "crystalizing " those ideas into

Maybe some of you already had the idea, but take a look at the project
list (I should place it somewhere on, don't you think?):
1) JServ -> servlet engine
2) JMeter -> server tester
(proposed or partially written)
3) James -> mail server (MailServlet design on review)
4) Jam (Java Anserwing Machine) -> voice/fax server (VoiceServlet on
their way) [functioning and partially done]
5) Object-Oriented Database -> a way to get rid of JDBC and proprietary
database implementations [feasible?]
6) EJB Database -> middleware implementation for enterprise web app
7) The Java Apache Server Framework (a.k.a. JServ 2.0) -> a design
metodology for code reuse and integration of common technologies from
different server types. [highly needed in this picture]
8) PicoServer -> a micro HTTP 1.0 web server for web integration and
frontend with the other servers. [Note: this is NOT the java translation
of the Apache HTTP web server and never will be]
(servlet projects)
7) Page Compilation Servlet -> pluggable support for all kinds of
languages GSP, JSP, WebMacro, etc This is for easier/faster servlet
8) XML/XSL servlet -> a servlet to allow easier deployment/use of
XML/XSL as publishing framework [already written by myself on IBM/Lotus

Do you see the picture? This is what I call "the Java Apache Project":
the server family you need for your enterprise written in the confort
(and the hype :) of the Java language.


Stefano Mazzocchi       A language that doesn't affect the way you
                      think about programming, is not worth knowing.
<>                             Alan J. Perlis

------------------------------- cut here -------------------------------

This is my first public comment on XML/XSL, Wed, 27 Jan 1999 17:46:06 +0100

------------------------------- cut here -------------------------------

One thing is for sure: HTML generation is getting more and more
pointless. A clear separation of logic/content/style cannot be provided
by ANY of the currently available frameworks but, maybe, WebMacro
( which is the only server side logic which is
orthogonal to the SGML format.

Again, the use of static XML + XSL stylesheet is the way to go for
modern web design/engineer. I'll hardly change my opinion on this.
Currently, I don't see a bright future for client-side XSL/XML
integration while I believe they win on the server side where the
content/style are produced, while HTML/CSS win on the client side where
content/style is rendered. Yes, XML/XSL are much better than HTML/CSS
and, I hope, this model will replace completely older ones. It will be
hard to remove HTML from the picture, though. So, server side processing
should be the glue between past, present and future, allowing the
seamless integration of both technologies.

I already have my homepage generated from XML/XSL and rendered into
well-formed HTML. As soon as Brian installs JServ on (he
is going to :) I'll be able to show the power of this publishing
framework using this servlet. Next goal is to prove the concept thru
redesign of in XML.

BTW, Java is the present/future of server side programming, XML is the
present/future of data interchange, XSL is the present/future of style
and transformation. We should bet on all them. (I sure did ;)

------------------------------- cut here -------------------------------

NOTEs: WebMacro was forked for licensing reasons to create what is now
Velocity, but the concepts remain the same.

"I'll hardly change my opinion on this": I was wrong :-) As others (Tim
Bray, for example) I'm getting more and more sick of XSLT in favor of
simpler solutions like CSS and STX.

"XML/XSL are much better than HTML/CSS": I still think so! even if it is
comparing apples and oranges. I would say that XHTML+CSS+XSLT is better

"server side processing as a glue between past and present web
technologies": this doesn't sound as 4 years old in a web which is only
10, doesn't it? :-) Amazing.

This is the email where I explain my vision of what Cocoon should have been:

------------------------------- cut here -------------------------------

Date: Thu, 28 Jan 1999 00:14:56 +0100
From: Stefano Mazzocchi <>
To: Java Apache Servlet List <>
CC: "Eric Prud'hommeaux" <>, Scott Boag
<>,Justin Wells <>,Gary Lawrence
Murphy <>
Subject: Web Publishing Framework and the (proposed) eXtended Logic

Assaf Arkin wrote:
> > One thing is for sure: HTML generation is getting more and more
> > pointless. A clear separation of logic/content/style cannot be provided
> > by ANY of the currently available frameworks but, maybe, WebMacro
> > ( which is the only server side logic which is
> > orthogonal to the SGML format.
> How about this for XML generation framework: a Servlet loads an XML
> from a cached template, the document is then represented as an object tree
> (the DOM API), so the Servlet can add, remove, duplicate and move elements
> around with a nice API rather than working with strings, the document is
> then validated (if necessary), compresses (optional) and send to the
> This modrl is very similar to Netscape's app server (previously Kona) and
> Applet's WebObject (previously NextStep), but it relies solely on standard
> APIs.

Hmmm, look: don't want to start a war on content generation
languages/scripts/tools but here is what I think about the subject (it's
been a while I'm thinking about this and it's time for the world to know
about it):

1) I was writing my homepage using HTML and got sick and tired of it
pretty soon. I wanted nice graphic design and nicely updatable content.
I knew XML and barely XSL so I said "what the hell" and started taking a
look at it. It is awesome: it was what I always wanted without even know

2) So I decided to write the pages with XML/XSL using the just released
LotusXSL engine. I tried a couple of pages and wrote some myself. I
tested the implementation porting the graphic style of
tables with XSL. Result: the same page in XML with just content is a
piece of cake to update and XSL stylesheets may be cascaded and reused
on different pages. This showed me a different world.

3) Next: IE5 will support XML/XSL but I want it now and for everyone.
Solution: XML/XSL servlet. I went for the first one and implemented it
based on DOM and usign the polymorphic factory pattern and a couple of
intefaces: parser, processor, styler and formatter. The whole thing
implements the pipes and filters pattern.

- "parser" creates the DOM Document from a stream
- "processor" takes a DOM Document and returns a DOM Document
- "styler" takes a DOM Document and returns a DOM Document
- "formatter" serializes the DOM Document to a stream

Now, I wrote implementations for all four filters, but stopped on the
processor filter.

[doing this I found a bug in the LotusXSL code and, without the source
code I wasn't able to fix it. So I suggested Lotus to release the source
code to avoid those problems and, guess what?, they did (they also came
out with the XML servlet "after" I talked to them about it what I was
doing, how strange... ;-)]

4) So I went on and evaluated the possibility to adapt currently used
solutions (page compilation, template systems) to the framework. Why I
did this? XML is easy to write because gives you just syntattical
constrains but no content restrictions: you can use valid XML and forget
about DTDs and all that. You write what you like the way you like it
just following the simple XML syntax rules. That's awesome compared to
HTML for a web designer: you write the content and others will format
it. Do you need format rules between the two groups? all right, write a
DTD. Otherwise go ahead and do as you like.

I needed something that worked the way XML works giving me the ability
to write dynamically generated XML without making it appear "dirty". So
I went on...

5) I came out with this document model. These are the four things you
need to create a document

- "data" is all the raw information you have access to (in your brain,
your computers, your books, wherever).
- "processor" the actor that performs the data processing (your brain,
your servlet, whatever)
- "logic" the instructions for the processor (brain patterns or code)
- "content" the processor output.

You generate your document after one of more processing cycles on one or
more different processors. Please, note that one thing may turn into
another after the processing cycle: content may turn into data/logic for
the next processor.

When do we have a "clean" document generation process? when we can apply
the pipes and filter pattern to this framework without making the
contexts overlap. I explain further: if content and style are written in
the same file (like HTML) two "processors" overlap because they have
different "logic" for the two "data". The solution for static pages (all
human processing) is XML/XSL.

For dynamic pages, the things get complicated by the fact that logic
must be clearly expressed in the document environment. This is still an
open problem since I didn't get an good enough solution to make forget
the others. Using this framework I evaluated existing technologies:

- Page Compilation Systems (JSP, GSP)

+1: they allow a good separation of "logic" from "content". They can be
used to generate XML compiled pages.
-1: logic separation is not required but suggested (which is a +1 for
some), their syntax is not orthogonal to SGML and XML parsers cannot be

- WebMacro

+1: separation of code from documents is required and considered a major
goal. The syntax is orthogonal to SGML so XML parsers may be used.
-1: doesn't currently support page compilation (implementation problem:
the syntax allows it)

- Template systems in general

+1: very good separation from "logic" and "content"
-1: very strict syntax (they usually use their own DTD) not always XML
compatible. Hardly compilable. Very sensitive to extentions and thus
fragmentation (against the soul of XML)

I go on and evaluate Arkin's proposal (as far as I understand it, I
apologize if my assumptions are wrong):

- DOM processing APIs

+1: very flexible. Excellent separation of "logic" and "content".
-1: not much different from the DOM itself.

If I understand correctly, you want to create some useful APIs for the
"processor" interfaces (not the one describing the document model, but
the one I outlined in my servlet). You have to write your own processor
that follow your particular DTD, compile them and associated them with
the right DTD or file. Like I said: very flexible, nice separation but a
pain in the ass to manage.

I go a step further and explain the directions I would like to take:

6) eXtended Logic Language (XLL)

The step is pretty simple seen in this framework: you have two "cooked"
XML files, one for content and one for style that were created using
different processors. I would like to see another XML file in this
model,written following the XLL DTD that would allow to "evaluate" and
"process" the XML file.

Here is the atomic picture:

  Data + Logic = Content

Note again: data, logic and content may turn one into another from one
processing cycle to the next one. Cooked data for a processor may even
be data or logic for the next. So you get:

1) raw data + brain login = XML content

2) raw graphic data + brain art/logic = XSL stylesheet

3) XML content + programming logic (XLL) = dynamic XML content

4) dynamic XML content + stylesheet logic (XSL) = final transformed

documente (i.e. HTML)

This XLL language should be an XML document and should incorporate the
instructions on how to expand, process or otherwise act on the XML raw
content. This would allow:

1) perfect separation from logic, content and style in three different

2) complete parallel development led by the content producer (the
central role of web engineering)

3) increased logic reusability: more pages can use the same logic.

4) page compilation of the XML/XLL/XSL model is possible (even if not
complete since some XSL processing is always needed at runtime for the
dynamically generated XML

I do believe this is what a nice web publishing framework is lacking
today: the ability to add programmatic logic to the page without
requiring to follow a particular syntax/DTD. XLL (like XSL) works on a
generic XML file and transform it into something else.

I do admit XLL and XSL seem very closely related but I don't think they
completely overlap since the XSL language was designed for the client
side and XLL will be used on the server side only (or not?).

Gee, I hope this doesn't start a war...

CC-ed people: please, feel free to contribute back (or to forward this
to those people you think would be interested in earing this) to this
subject directly to me and I will summarize the responses for the list.


Stefano Mazzocchi       A language that doesn't affect the way you
                      think about programming, is not worth knowing.
<>                             Alan J. Perlis

------------------------------- cut here -------------------------------

This is the "cocoon project creation proposal email", sent by myself on
Sat Feb 20 01:05:14 1999 (yes, 01: is AM! of course, those days I only
worked at night) to

------------------------------- cut here -------------------------------

Hi guys,

since may people contacted me privately to know about my XML/XSL
servlet, I'm more than willing to donate it to the Java Apache Project
as a pure-servlet project.

The Cocoon servlet is based on the pipes and filters pattern and does

  XML parsing --> XML processing --> XSL processing --> DOM formattation

The requested file is parsed and a DOM tree is created.
The DOM tree is evaluated and programmatically processed (this is yet to
be done, currently it doesn't do anything to the DOM tree)
The DOM tree is processed thru an XSL processor.
The DOM obtained is formatted to the servlet output stream and sent back
to the client.

Why would you need this servlet?

To write content,logic and style on three different files, to
parallelize web development maintenance, to place different skill
requirements on different places and to simplify data reuse.

The Cocoon servlet is probably going to be the logic behind the Java
Apache web site, once we get JServ installed on Hyperreal (Brian, are
you listening? ;-)

The big problem is the logic file: at present I don't know how to do it
and I'm also thinking about proposing a new server side language (which
I called eXtended Logic Language, XLL) to the W3C or to extend XSL to be
server side programmatical.

Arkin and I thought about this but we didn't come to a settling point.
Maybe others have better ideas. Let's find out.

Why "Cocoon"? Well, did you see the movie? I got the idea while watching
it: bring old technology like dynamic web content generation to a new
life. Besides, I like fancy names much more than acronims. They are more
"juicy" :)

My vote request is: do you people care to see such servlet project
carried on by the Java Apache Project?

If so, I'll donate it with the normal Apache license, even if I won't
have that much time to stay after it for a while.

Stefano Mazzocchi       A language that doesn't affect the way you
                      think about programming, is not worth knowing.
<>                             Alan J. Perlis

------------------------------- cut here -------------------------------


 1) "Arkin" is Assaf Arkin, author of the xml parser used by the very
first Cocoon implementation and co-author of Castor and now CTO of
Intalio (ex Exoffice Technologies, former employers of Ricardo when he
wrote the XSP engine, Pier when he wrote the first implementation of
Cocoon 2.0 and Federico when he was dealing with Avalon and James)

 2) XLL was later renamed XSP

 3) after more than 4 years, we still don't have a running cocoon on ASF

                                 - o -

Now, I think that mbox file might be useful for digital archeology
purposes. What should I do with it? place it in
once we move all the mail lists there? submit it to MARC? how would the
fact that the mail list changed email address impact their database?

oh, well, anyway, the important part is that the data wasn't lost.

Ah, kudos to "Davison, Nicholas" <> for being
the one who sent the first message to the mail list on Tue Mar 16
23:34:19 1999

By any chance, is there anybody that has been around since than?


View raw message