cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject [RT] "To Cocoon2 and beyond" :)
Date Fri, 25 Feb 2000 17:37:41 GMT
NOTE: [RT] stands for "random thoughts", so skip this mail unless you
really want to. You have been warned.


with the Cocoon2 development in progress (thanks Pier!) I'm left with
almost nothing to do (I should write my thesis or study... but I'm lazy
:), so I'm starting to rethink the picture over again to see if
something is missing.

... hear that sound? is Pier screaming :)

No, no, don't worry... I'm not re-evaluating the architecture, not at
all, I'm just looking for holes in the global picture.

There are at bunch of things that are currently missing in Cocoon1 that
I would like to add to Cocoon2. These are:

1) DirectoryProducer

Map a directory producer that generates a marked-up list of the files
contained in that directory. This can then be processed and styled at
need. (thanks to Armin Pfarr for the suggestion on this, but also Pier
did this for Stylebook)

Don't you hate "http:/" looks so out of place?
Wouldn't it be nice to have a common look and feel throughout the entire
web site? Well, this will do it.

2) Enterprise taglibs for XSP 

the object -> relational binding logic sucks. This is evident to
everyone that ever wanted to push an object into a database. People are
talking about OODBMS... I still have to see one that does what I want,
but it seems that EJB is what we need.

Something as simple as

 <ejb:bean name="shopping-cart">
  <ejb:set name="itemĀ°>
   <form:get name="item"/>
 <ejb:commit bean="shopping-cart"/>

now, _THAT_ is something useful... not the SQL crap we have to embed
into our logic. Sure, if you already have relational data and you want
something out of it, use donald's sql taglib and you'll be set for
life... but like if you want to use your DBMS for store ACID
transactions out of your pages... hmmmm, sql is expensive thing to do
and, in my opinion, too different from the highly object-oriented Cocoon

You should have noted, by now, that Cocoon is highly polarized in a
server -> client direction. While there are a bunch of tools to get data
out of someplace and presented to you in the fanciest looks, it lacks
serious attempts to go the other direction.

But what does "going in the other direction" mean?

Good question.

Donald proposed the use of inlined-xpath to create structured
otherwise-flat html forms. While I think this is a very clever use of
XPath, I strongly question the idea: why should I embed the structure
inside the form? Does it really stay there? Isn't this breaking the
separation of contexts?

Let's move on.

3) SOAP support. (??? I really don't know about this.. Flexibility

SOAP (Simple Object Access Protocol) is an internet draft
(draft-box-http-soap-01.txt) that specifies a way to use XML-over-HTTP
for remote procedure calling and data transport.

SOAP doesn't address a bunch of things like distributed gargabe
collection or bi-directional HTTP communications. So it's not a
CORBA-light thing, but a nice way to use simple existing code and
knowledge to do powerful things.

a SOAP request looks like this:
   POST /StockQuote HTTP/1.1
   Content-Type: text/xml
   Content-Length: nnnn
   SOAPMethodName: Some-Namespace-URI#GetLastTradePrice

   <SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1">
       <m:GetLastTradePrice xmlns:m="Some-Namespace-URI">

and the response is something like this:

   HTTP/1.1 200 OK
   Content-Type: text/xml
   Content-Length: nnnn

   <SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1">
       <m:GetLastTradePriceResponse xmlns:m="Some-Namespace-URI">

Now, look carefully. Cocoon is already able to handle this:

Ok, a better approach would be to write a producer that reacts on the
"SOAPMethodName:" header and connects to the right object and does all
that introspection and reflection things and then generates the response
output directly....

or we can use simple producers and do the evaluation with filters...
anyway the architecture is able to stand this with no problems. :)

Now the question: should Cocoon care about this? Normally SOAP is
considered a way for simple clients to interact with object
repositories... a simpler way to use ODMG + remote logic. Much simpler,
in any case.

We could picture something like this:

 browser <-> HTMLoverHTTP <-> cocoon <-> SOAPoverHTTP <-> cocoon <->

but maybe using cocoon for the last step is a little bit too much... in
fact, creating a SOAP server is a piece of cake once you have
http-handling classes (tomcat) and an xml parser (xerces).

We'll see. anyway, we won't be surprised when something like this gets
asked. :)

4) Internal logging.

Well, this is in the Cocoon1 todo list but I'll implement it in
Cocoon2... I saw the IBM Log4j package and sounds pretty good. Another
option would be to use Avalon's Omero... we'll see.

Anyway, internal logging will be a must when the pipeline will be in

5) RDF+RSS/CDF support.

Like for SOAP, the Cocoon architecture is XML-schema-neutral from the
ground up so you can do whatever you want with all the schema you wants.
But the RDF+RSS/CDF couple is _very_ interesting (see the JetSpeed

A breif explaination: 

RDF stands for Resource Description Framework and it's a W3C
Recommendation issued three days ago over more than 2 years of work!!!
RDF is one of the oldest XML research projects and, let me tell you, one
of the most brilliant.

RDF is not even a language, but a framework, a namespace that should be
intermixed with your own namespaces (whatever you want, even XHTML) to
specify some information _about_ the content.

things like "document abstract, key words, authors" and the like should
be indicated with the proper elements, but some RDF meaning should be
added to allow, say, indexers or crawlers to retrieve information about

RDF specifies "metadata", that is "data about data". Just like XML is a
"meta-language", a "language for languages".

RSS is Netscape's "Rich Site Summary" and CDF is Microsoft's "Channel
Description Format".

Both do the same thing: create sort of simple indexing about the site
they refer to. For example, let's look at the Mozilla automatic RSS file

<?xml version="1.0"?>
 <title>Mozilla Dot Org</title>
 <description>the website</description>

 <title>XPInstall Newsgroup</title>

 <title>Open Source PKI Code Released</title>


as you see, it's pretty easy to create a simple HTML sidebar from this
file... your way to keep under control.

If you look at$235

there are hundreds of such RDF+RSS news services listed. A real gold
mine. Slashdot, Freshmeat and all the key information sites can be found
there. Not as intrusive as PUSH technology, but a great amount of

Anyway, Cocoon can do two things:

 a) use the RSS info with user preferences to create specific collection
of resources (sort of a portal building toolkit, which is what the
JetSpeed project is all about)

 b) generate the RSS info out of pages contained inside out of RDF

While point b) doesn't require any special logic (just a wise knowledge
of the DTDs involved), point a) requires at least some
ProducterFromURL... but how do we create a page out of a collection of
different resources coming from different places?

5) Template Driven Publishing

Which leads us to the my main concern: real life publishing.

All my experience as web designer/engineer comes from content-driven
publishing and you can tell from what Cocoon is like today.

But people coming from different publishing areas (newspapers) know that
is the "layout" of the page that drives the process, not the content.

Layout is not style. Layout is about partitioning a 2d space into areas
and assigning those areas to particular content generators. The Turbine
framework includes this in detail, but it's limited to a web-oriented
layout due to HTML constraints.

Now, let us suppose you want to create your web site on a piece of paper
to show your boss. What do you do first?

You draw rectangles! Here goes the logo, here the news, down here the
counter, the sitebar with the slashdot news, the weather forecast for my
town, up on the left the links to the other resources...

You're a programmer, right? You know nothing about style, you can't
draw, you can't even think of cool graphics or icons or those things...
but you _do_ see how the layout should look like. You know this by
experience, you've been surfing the net forever and you know where to
place the right information... maybe not which font or color or
background, but you know what should go where.

Everybody does.

Layout driven publishing is the design pattern that emerged after
-hundreds- of years of newspaper publishing. Should the digital age
throw it all away? No way, dude!

So, the question is: is Cocoon ready for layout-driven publishing? yes
and no.

I explain: the main question is "is the web ready for layout-driven
publishing?", the answer is "almost".

Let us suppose for a moment we have a Layout Description Language (LDL).
This language is what drives the page construction process. For example:

<l:page xmlns:l="layout" xmlns:c="cocoon">
   <l:item width="100%">
    <c:generator c:type="url" c:src="logos/logo.nrg"/>
    <c:namespace prefix="nrg" url="http://cocoon/dtd/nrg"/>
   <l:item width="30%">
    <c:generator c:type="dir" c:src="."/>
    <c:filter c:type="xslt">
     <c:parameter c:name="stylesheet" c:value="dirs2links.xsl"/>
    <c:namespace prefix="link" url="http://cocoon/dtd/link"/>
    <c:generator c:type="file" src="*"/>
    <c:namespace prefix="doc" url="http://cocoon/dtd/doc"/>

which represents a layout-centric view of the current

Note, in fact, that there is a big difference between a layout and a
skin. A layout does not have styleinformations. In fact percentage-based
item width is not style, but layout.

True, one could easily picture another separation done like this:

  <content url="*"/>

then then apply a "layoutsheet" to tell how much of the page should be
occupied by the sidebar.

The question: is the above possible in Cocoon2? yes, it is.

I picture the above layout transformed into XSP after authoring and then
compiled into a generator.

note that the above does not indicate _how_ the page should be
formatted!!!! In fact, the above does not collision with the sitemap,
rather the opposite: is simplifies the sitemap operation by doing
further separation of contexts inside the content-creation context.

Sure the line gets blurred a little, but I'm confident something like
this will be extremely powerful once we have a good FO+SVG+NRG renderer
in place.

yes, because everything should be formatted by FOP! The best thing would
be to use formatting objects _always_ as the output format and have
formatters taking care of the HTML generation automatically, depending
on client properties.

sheesh, that was long.

Sorry about that, but I hope to have given you food for thought :) take
care and digest it slowly.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

View raw message