Return-Path: 
 <dev-return-46759-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 65264 invoked by uid 500); 25 Aug 2003 09:29:37 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 65144 invoked from network); 25 Aug 2003 09:29:35 -0000
Received: from mailserver1.hrz.tu-darmstadt.de (130.83.126.41)
  by daedalus.apache.org with SMTP; 25 Aug 2003 09:29:35 -0000
Received: from paris (paris.dvs1.informatik.tu-darmstadt.de [130.83.27.43])
	by mailserver1.hrz.tu-darmstadt.de (8.12.9/8.12.8) with ESMTP id
 h7P9CfJZ025171
	for <dev@cocoon.apache.org>; Mon, 25 Aug 2003 11:12:41 +0200
Received: from bremen.dvs1.informatik.tu-darmstadt.de (bremen [130.83.27.69])
	by paris (Postfix) with ESMTP id B8F9AFE20
	for <dev@cocoon.apache.org>; Mon, 25 Aug 2003 11:12:41 +0200 (MET DST)
Received: from haul by bremen.dvs1.informatik.tu-darmstadt.de with local (Exim
 3.36 #1 (Debian))
	id 19rDOz-0007rk-00
	for <dev@cocoon.apache.org>; Mon, 25 Aug 2003 11:12:41 +0200
Date: Mon, 25 Aug 2003 11:12:41 +0200
To: dev@cocoon.apache.org
Subject: Re: [RT] Implementing Cocoon Blocks
Message-ID: <20030825091241.GK1259@bremen.dvs1.informatik.tu-darmstadt.de>
Reply-To: haul@informatik.tu-darmstadt.de
References: <4CD93AAB-D0D4-11D7-A92A-000393D2CB02@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4CD93AAB-D0D4-11D7-A92A-000393D2CB02@apache.org>
Organization: Databases and Distributed Systems Group,
 Darmstadt University of Technology
User-Agent: Mutt/1.5.4i
From: Christian Haul <haul@dvs1.informatik.tu-darmstadt.de>
X-MailScanner: Found to be clean
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

On 17.Aug.2003 -- 07:00 PM, Stefano Mazzocchi wrote:
> 
> Issues that were still unsolved
> 
> 
> 
> 1) block identification
> 
> All blocks (behaviors and implementations) are identified by a URI. the 
> format of the URI is as follows:
> 
>      cob:organization/name/x.y(.z)

If we would identify a block by an XML document instead of a URI, we
could list features of a block. Version numbers are a very poor tool
to match requirements and capabilities. Then we could solve

>  2) dependency ranges
> 
> When a block implementation depends on another block (either 
> implementation or behavior), it should be able to have an 'elastic' 
> dependency which doesn't connect it to the versioned identifier, but to 
> a range of those versions.

by using another XML document that lists required features. This way
it would be easy to decide if two blocks a compatible.

Those two documents, let's call them requires.xml and provides.xml,
could reside in the meta data subtree of the archive. The requires.xml
would need to declare a URI for every block it depends on which is
used to refer to it.

Example
=======
(This example is probably poor but should still illustrate the idea)


block "really cool skin"

<provides-features>
   <feature name="html-skin"/>
   <feature name="wml-skin"/>
</provides-features>

<dependencies>
   <block name="core" uri="core">
      <feature name="html-serializer"/>
   </block>
</dependencies>

<map:sitemap>
 <!-- ... -->

  <map:transform src="cob:core/html-skin"/>

 <!-- ... -->
<map:sitemap>

Now, the block manager would select the block with the highest version
number that provides all required features and would map the
"cob:core" prefix to that particular block.

	Chris.
-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08