cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Implementing Cocoon Blocks
Date Sat, 13 Sep 2003 16:31:29 GMT

On Sunday, Aug 31, 2003, at 15:04 Europe/Rome, Christian Haul wrote:

> Stefano Mazzocchi wrote:
>> On Wednesday, Aug 27, 2003, at 11:35 Europe/Rome, Christian Haul 
>> wrote:
>>> Which is the whole point of my mail. Don't use dependency ranges, use
>>> metadata specifying capabilities and requirements for this.
>> I think you greatly underestimate the complexity of the approach you 
>> are proposing.
>> Last thing I want is to enter the ontology problem space.
>
> There is absolutely no need to go the full way and I don't suggest to 
> do it. A simple list of features that are matched 1:1 would be orders 
> of magnitude more powerful than version numbers.
>
>> But in case I'm missing your point, please provide an explicit 
>> example.
>
> Actually, I have already provided one:
>
> <provides-features>
>    <feature name="html-skin"/>
>    <feature name="wml-skin"/>
> </provides-features>
>
> <dependencies>
>    <block name="core" uri="core">
>       <feature name="html-serializer"/>
>    </block>
> </dependencies>
>
> This would be a very simple block that has little requirements and 
> provides few features.
>
> Let's look e.g. at the databases block. For ease of use, let's assume 
> that any tag appearing beneath "provides-features" is a name of a 
> feature and let's assume that features may have sub-features:
>
> <provides-features>
>    <esql>
>       <stored-procedures/>
>       <grouping/>
>       <get-xml/>
>       <get-clob/>
>       <get-blob/>
>    </esql>
>    <sql-transformer>
>       <stored-procedures/>
>       <get-xml/>
>       <get-clob/>
>       <get-blob/>
>    </sql-transformer>
>    <db-actions>
>       <add/>
>       <update/>
>       <delete/>
>    </db-actions>
>    <mod-actions>
>       <add>
>          <autoincrement>
>             <oracle/>
>             <informix/>
>             <mysql/>
>             <postgres/>
>             <hsqldb/>
>          </autoincrement>
>       </add>
>       <update/>
>       <delete/>
>       <query/>
>    </mod-actions>
> </provides-features>
>
> Now, another block might require the following:
>
> <dependencies>
>    <block name="databases" uri="db">
>    <!-- *this* block will refer to the block satisfying
>         the requirements as "cob:db" -->
>       <esql>
>          <grouping/>
>       </esql>
>       <sql-transformer/>
>    </block>
> </dependencies>
>
> Which is apparently compatible. Even without knowing the semantics of 
> a feature "esql" hence without ontologies.
>
> OK, this is more expensive than comparing to integers. OTOH this will 
> occurr only once when a new block is registered.

I am afraid of going down this path because you are not taking into 
account:

  1) semantic collision
  2) increased development/maintenance complexity due to more granular 
dependendies

even providing a fully namespaced taxonomy, the amount of "topics" 
would grow rather quickly and would also get into the "keydata 
syndrome": what is a keydata for me might not be for you.

so, in order to depend on a block, you would not only need a 
dictionary, but a full thesaurus.

which, at the end, will end up being an ontology.

and this path scares me already too much to be willing to get into it.

--
Stefano.


Mime
View raw message