Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <38BAD951.1BC7E1DD@apache.org>
Date: Mon, 28 Feb 2000 21:23:45 +0100
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: Cocoon <cocoon-dev@xml.apache.org>
Subject: [RT] Layout-driven vs. content-driven
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi guys,

here is another episode of the "Stefano's random thoughts" series. The
title says it all.

I've been addressed by some that think that Cocoon is heavily
content-biased. This implies that Cocoon doesn't work well where the
structure of the page is the key and the content is just that,
content... what rules is the container.

I believe the above is not correct if you look at Cocoon under the right
perspective.

1) layout is another form of content

2) cocoon doesn't assume anything about what is "generated" to start the
pipeline process. It could contain the data to present, or may contain
data that is used later in the stage to trigger execution.

Now, the real question is: is Cocoon ready for a layout-driven approach?

The final answer is: its architecture is, its implementation is not.

I'll outline what I believe is a possible solution for the problem...
but first we must outline the problem.

Consider something like this

   +----+-------------------+
   |logo|      topbar       |
   +----+-------------------+
   | s  |                   |
   | i  |                   |
   | t  |                   |
   | e  |                   |
   | b  |                   |
   | a  |                   |
   | r  |      content      |
   +----+                   |
   | n  |                   |
   | e  |                   |
   | w  |                   |
   | s  |                   |
   +----+-------------------+

which represents a site layout (please, don't abuse me if you don't like
the visual appeal, my point is structural, not visual)

Let us suppose we have a layout-definition language. This language
should:

 a) identify content containers
 b) define their structure and relationship between them
 c) contain the instructions on how to fill-up the container the with
proper content
 d) be reusable across the site
 e) contain metadata about the containers (optional)

however, it should not:

 a) contain any stylying/visual information
 b) contain any content processing information

Such a language does not exist, but there is an equivalent in the HTML
world: framesets. When you define frame-driven web sites, you write an
entry html page that specify the layout of the page, frame-wise. Then,
the browser will connect to the required frames and place the responsed
content in the visual containers.

Now, suppose you have a way to define the structure of you page without
explicitly including visual information... you could have a way to
"construct" your page, structure-wise, with different content (a-la
portal) and care about their visual representation later.

Also, this page should be able to be processed on the server side and
the architecture should do the inclusion for us, instead of the browser.

I have no idea of how this language should look like (yet), but one
thing is for sure, Cocoon lacks a very important piece of the puzzle:
XInclude!!

XInclude is a W3C note, it's not even a working draft, but it's a very
high quality note and cames from the work of the XLink WG. Please, take
a look at: 

  http://www.w3.org/TR/xinclude

XInclude specifies a way to include a document or parts of a document
(using XPointer and XPath) in the original XML document. As they say,
"merging a number of XML Infosets into a single composite Infoset".

Now, let's look again at a possible marked-up representation of the
layout

 <area name="page" xmlns:x="http://www.w3.org/1999/XML/xinclude">
  <area name="top">
   <area name="logo">
    <x:xinclude x:href="/images/logo.svg" x:parse="xml"/>
   </area>
   <area name="bar">
    <x:xinclude x:href="/images/topbar.svg" x:parse="xml"/>
   </area>
  </area>
  <area name="side">
   <area name="index">
    <x:xinclude x:href="/index.fo" x:parse="xml"/>
   </area>
   <area name="news">
    <area name="mynews">
     <x:xinclude x:href="/news/mynews.fo" x:parse="xml"/>
    </area>
   </area>
  </area>
  <area name="content">
   <x:xinclude x:href="/docs/content" x:parse="xml" x:steps="2"/>
  </area>
 </area>

which identifies the structure of the page in terms of contained
information

 page 
  +-top
  |  +-logo
  |  +-bar
  +-side
  |  +-index
  |  +-news
  |     +-mynews
  +-content

and identifies what content should be included and where to get it.

So, what we need is an "XIncludeFilter" that looks for "xinclude"
elements and replaces them
with the result of the subrequest. In sitemap notation:

 <generator type="file" src="/layout/standard"/>
 <filter type="xinclude"/>
 <filter type="xslt">
  <parameter name="stylesheet" value="layout2fo.xsl"
 </filter>
 <serializer type="fo2html"/>

assuming that all the other requests are handled by pipelines that
generate FO as their result.

Not all the issues have been resolved with this approach and performance
tuning and caching and pre-compilation should be addressed later on, but
consider this food for thought.

Enjoy, and stay tuned for another epidode of the series "RT: live from
Stefano's damaged brain cells" :)

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