cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Cocoon2 Design WAS: [cocoon 2] removing bottenecks
Date Thu, 25 May 2000 00:16:57 GMT
I'm happy when I find different views of the problem.

David Wagner wrote:
> Sean T. requested:
> > Cocoon2 is only in alpha-mode, so if the design is etched in
> > stone, it's probably only soapstone.  I'd be interested in
> > hearing more about the design difference.
> >
> I am not entirely clear on the Cocoon 2 design (in particular the difference
> between code generation and markup delivery), but assume the following blurb
> from sums it up.
> "This new paradigm is based on fact that document content, style and logic
> are often created by different individuals or working groups. Cocoon aims to
> a complete separation of the three layers, allowing the three layers to be
> independently designed, created and managed..."
> When I looked closely at the content and style of an entire site by putting
> each into a separate XML document, I found the logic needed to lay out
> elements in the site may be *inferred* from well-structured content
> (especially if it contains adequate metadata) and style, rather than
> *specified* in a separate logicsheet.  Essentially, the structure determines
> the logic.  

Hmmm, I'm not sure you understood what we mean with "logic". For "logic"
I mean all the programming effort that is required, for example, to
connect to a database, get data out and format it to XML.

But this happens only at server side dynamic generation, if you focus on
static content, you are right, there is no logic to be separated.

> So I cut my system design to just two layers: content and style.

You can do this _only_ when no dynamic generation takes place.

> One XSLT file (with extensions to handle multiple output docs) slices and
> dices the content and style docs to deliver the markup appropriate for the
> requesting user agent.  It relies on the structure of the content and style
> docs to determine what goes where, and how so.
> content(partRequested) + style(userPrefs) -> delivered docs
> In addition, this simple design solves other problems, including the
> following from the same source as above.
> "Another problem is the intrinsic impossibility of page-compiling all the
> three processing layers, due to the post-processing requirements of XSL
> styling. This problem will be solved (hopefully!) with the availability of
> XSL-enabled web browsers since the XSL rendering would be then performed on
> client side reducing the server work."
> My goal is to get the content to the user in the most efficient and
> effective manner (effectiveness includes attractiveness).  There is little
> client-side processing needed if the content is delivered already optimized
> for the client requesting it.  Also, remote caching of relatively static
> content is a good thing.  (Let's face it; most content is relatively static
> if you don't have to rewrite it for every browser release.)

Again, you are preaching to the converted: during the last few days we
have been discussing how to implement the Offline generator for Cocoon2.
> In summary, what I realized is that the content of this system is a resource
> description framework (RDF as defined by the W3C) in *reverse*; it describes
> a resource (commonly called a web site) to be created from the RDF.  

Interesting vision... but I think you're right.

> The
> style XML doc is needed to deliver the content described in the RDF
> according to user preferences of protocol, markup language, accessibility
> options, plugins available, screen resolution, and so on.

Yes, the sitemap is the RDF equivalent and cocoon is the engine that
"merges" this information to provide resources.

Anyway, I'm sorry, but I cannot understand _where_ your views would be
different from ours.

I probably missed one of your points and I apologize in advance for

> -David
> P.S.  Slap the arrogant American; I forgot to mention I (unfortunately) have
> only English-language skills to offer, though I may be able to bribe my
> significant other for help; she is fluent in five languages.  :)

I think we should concentrate on English. Documentation is already
difficult without messing up with natural language translations.

Thanks anyway, maybe for localized messages, but I think we have far
more than five different countries represented on this list :)

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message