Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 80236 invoked from network); 29 Feb 2000 03:47:00 -0000 Received: from dnai-216-15-97-206.cust.dnai.com (HELO kali.betaversion.org) (216.15.97.206) by locus.apache.org with SMTP; 29 Feb 2000 03:47:00 -0000 Received: from apache.org(kali[216.15.97.206]) (3318 bytes) by kali.betaversion.org via smail with P:esmtp/R:internet/T:smtp (sender: ) id for ; Mon, 28 Feb 2000 19:47:58 -0800 (PST) (Smail-3.2.0.106 1999-Mar-31 #3 built 1999-Sep-21) Message-ID: <38BB4348.12F484DF@apache.org> Date: Mon, 28 Feb 2000 19:55:52 -0800 From: Pierpaolo Fumagalli Organization: Apache Software Foundation X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [RT] Layout-driven vs. content-driven References: <38BAD951.1BC7E1DD@apache.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Stefano Mazzocchi wrote: > > Hi guys, > here is another episode of the "Stefano's random thoughts" series. The > title says it all. I like it... I think I should start archieving them... > 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 was thinking RIGHT at the same thing... Yesterday at XTECH a guy asked me about Cocoon 2.0 and frames, and one of those idle tasks started in background in my brain... > 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. The HTML spec addresses one specific thing: How to display multiple sources into one single "view"... > 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 While XINCLUDE addresses another problem, how to merge different source documents into one. The two functionalities are "different" imo. In the first case (frames) you deal with multiple URIs represented into the same "view", while in the second one, you have one unique URI... It's kinda hard to put it down in words, the thought is yet a little bit cloudy, and deals mostly with something I'm thinking about on the sitemap and link translations... > 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. It would be nice to have a xinclude processor... and actually it's kinda trivial to do it in cocoon 2.0, when you get the right element, you just "nest" another parsing operation... > Enjoy, and stay tuned for another epidode of the series "RT: live from > Stefano's damaged brain cells" :) Waiting for the next one (move it, I don't want to get old waiting) Pier -- -------------------------------------------------------------------- - P I E R - stable structure erected over water to allow the docking of seacraft -------------------------------------------------------------------- - ApacheCON Y2K: Come to the official Apache developers conference - -------------------- --------------------