cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Wagner" <dwag...@sa.kevric.com>
Subject Cocoon2 Design WAS: [cocoon 2] removing bottenecks
Date Wed, 24 May 2000 17:45:25 GMT
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 http://xml.apache.org/cocoon/ 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.  So I cut my system design to just two layers: content and style.
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.)

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

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


Mime
View raw message