cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Washeim" <>
Subject Re: [RT] "To Cocoon2 and beyond" :)
Date Sat, 26 Feb 2000 17:05:14 GMT
>NOTE: [RT] stands for "random thoughts", so skip this mail unless you
>really want to. You have been warned.

Random? :) Hardly, and thanks be to the gods of engineering that it ain't
'so'! (ok, thank Stefano it ain't so :) )

>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:set>
> </ejb:bean>
> ...
> <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.

We (company called Large Medium, owned by company called Critical Mass) have
developed a couple of prototypes using the KBML toolkit available freely
from Inria (Dyade). Namely, EJB Session Bean -> XML -> XSLT -> HTML (form)
and HTML (form) -> XML (DOM) -> EJB Session. We've also have an entity
version, though it's 'defunct' already, in our view (always favour the

DOM 'addressing' we're currently updating to use the most current Schema
specification. We're essentially using a Schema wrapper object composed of
Node and Attribute information objects. (sorry, this is a very brief

As with other projects we're working on currently, we're going to release
these with an Apache (FreeBSD style) license. In the main, I'm guessing that
the prototypes 'may' serve more as a point of departure than anything else.

For the EJB server we've been using Bull's jonas.

I'll provide links to samples ASAP (which means probably 1 to 2 weeks, given
current, mad, production schedules).

An expression of interest would be great, in the main, if people would
indicate whether they want to see a fully functional demonstration or just
design docs, etc. I need to actually assign someone to do the dist, so I'd
like to gauge interest....

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


>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"?>
> xmlns:rdf=""
> xmlns="">
> <title>Mozilla Dot Org</title>
> <description>the website</description>
> <link></link>
> <title>XPInstall Newsgroup</title>
> <link></link>
> <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
>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?

Again following the lead of Inria research engineers we're building some
'producers' from URLs. We've been using Info Extractor (package from Dyade)
which leans heavily on reg-exp, but provides a very clean means to produce
structured output from 'semi-structured' data (ie, especially well suited to
tabular data). As with the KBML prototype, we've built servlets which permit
us to, a) to the extraction and simply pass through 'raw' data, b) take the
output and transform it to XML on the fly. In our frame work context, XSL
transformations are never applied directly (all our tools use wrappering
(decorator pattern) to 'chain' consequtive operations on a stream) so the
objects in question are 'clean'. As above, we'll be happy to supply
examples, given a show of interest.

In any case, building a producer for cocoon, based on something like the
Info Extractor isn't directly relevant to the aims Stefano is expressing,
it's just an interesting example of a URL type producer.

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

 !!! RANT !!!

I disagree so vehemently with this statement that I'll try to contain
myself. Ignore this block if you're uninterested in theorectical

Almost everyone, in fact, is TOTALLY ignorant about what should be placed in
what position.

Witness the inumerable interfaces which place navigation bars on the LEFT.
Even in print publications, you can note a struggle over this question. A
paper like Die Zeit, in my opinion (stress opinion)  does it correctly. The
'lead' article is 'unencumbered' by anthing to it's 'left' on the page. When
you pick it off the stand, you read a headline and scan the first paragraph
without the movement of your eyes or your attention being impeded by other
elements in the layout. ALL the usual 'potted' summaries of contents (TOC)
are placed discreetly on the right. I believe that this is not only a
valuable strategy for the sake of reading (attention to content matter) and
'negotiating' (the movement of the eye accross the areas of the page) but,
happens, to nicely coincide with heuristics of interface design. Full
circle, at least for the right handed mouse user, the TOC should be placed
to the RIGHT, and by the scroll bar or most browsers.

Ok, I've been bitching at my clients and designers for years about this
issue. I'm not going to opine about it, but my point is that so very few
people know this, that it accounts for much of the disaster we're trying to
reel in, now. I mean: if more people understood the issues of the
organization and presentation of information, the WWW wouldn't be a 10th the
mess it is now.

I have the very good fortune of having worked with extrodinary designers and
engineers who ARE aware of the issues. Perhaps the one thing which is common
to them both is a reading of,
a) Edward R. Tufte's books (Envisioning Information and Visual Explanations)
b) good taste :)

I know that I'm charging at wind mills, as it were, but I want to point out
that we shouldn't assume that people's 'intuitive' notions about what should
happen in a layout will suffice to produce 'good' (ie, readable, functional)
'interfaces' to some data. In fact, I think that a lack of thought about the
implications of a 'presentation' are what have led to much of the mess we
see not only where layout is concerned, but also where the very fundemental
Data Structures themselves are concerned. I have a lot of thoughts about
this, but I'm actually working on an essay addressing them, and will leave
it out of this context.

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

I agree with this whole-heartedly!

>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:table>
>  <l:row>
>   <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>
>  </l:row>
>  <l:row>
>   <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:filter/>
>    <c:namespace prefix="link" url="http://cocoon/dtd/link"/>
>   </l:item>
>   <l:item>
>    <c:generator c:type="file" src="*"/>
>    <c:namespace prefix="doc" url="http://cocoon/dtd/doc"/>
>   </l:item>
>  </l:row>
> </l:table>
>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:
> <page>
>  <topbar/>
>  <sidebar/>
>  <content url="*"/>
> </page>
>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