cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: block perspectives
Date Thu, 02 Oct 2003 10:28:00 GMT

On Wednesday, Oct 1, 2003, at 16:22 Europe/Rome, Stephen McConnell 

> Stefano Mazzocchi wrote:
>> So, a few questions:
>>  1) where is the DTD of your block.xml?
> There is no DTD due to the fact that we wanted to include user 
> configuration directly in component directives.


> Instead we aim to apply  schema validation via tools - but this is 
> work in progress.  In the meantime there is the site documentation 
> that provides a reasonably complete picture of the block.xml 
> datastructure.

that's good enough.

Reading thru it:

  1) lack of polymorphic dependencies.

  2) lack of block metadata for human consumption.

  3) lack of extension capabilities.

  4) lack of block-level parameter definitions.

  5) definition of the component/service hint at the provider level

[I believe this is bad, the provider should specify the component ID, 
the compontent requirer should specify how it is hinted in its local 
domain of use]

  6) markup versioning and referencing are done thru DOCTYPE instead of 
namespace declaration.

>>  2) is that block.xml an avalon-wide thing or just merlin-related?
>>     [means: is that shared with Phoenix?]
> The block.xml defines a model relative to the Avalon Composition 
> package (the meta model definition). This package is based on the 
> Avalon Meta package which includes legacy support for the Phoenix 
> container.  Avalon Meta reads in Phoenix <blockinfo> descriptors and 
> transparently converts these to Avalon Meta Type descriptors. As such, 
> the composition package has no need to know about anything specific to 
> Phoenix as it is dependent on a Type descriptor which is container 
> independent.

Ok, Merlin only but phoenix compatible, right?

>>  3) how open are you/avalon to changes to this DTD?
> Totally open.
> However, a better question is how reasonable is it to extend the 
> deployment and composition object model instances.

Exactly. From what I listed above, the block composition model would 
have to be entirely redesigned to fit our needs. [which our current 
design already meets perfectly, I should note]

> This implies implementation of readers and writers that capture domain 
> specific (e.g. Cocoon value-added content) together with the 
> underlying Avalon structures.  Readers and writers currently include 
> XML and serialized forms.  In principal an extended form will be 
> possible - and more to the point - will be required independently of 
> Cocoon specific requirements simply to meet evolutionary needs in our 
> object model.

The Merlin block model lacks polymorphic dependencies. This is not a 
little cocoon-specific change, Stephen, this is the entire foundation 
of the concept!!

> I.e. think in terms of meta-model class extension - as opposed to DTD 
> proliferation.

Sorry but I can't parse this.

>> At the end, if collaboration is not possible, it would still be 
>> possible, for containers, to react on namespaces to understand the 
>> different semantics of the markup used (ah, btw, merin's block.xml 
>> don't use namespaces, that is generally a good future-friendly 
>> practice)
> This is a example of where expertise here can have a positive impact 
> on the core system development over on Avalon.

Simply write

  <container xmlns="">

and the cocoon block deployer will be able (would the need emerge) to 
understand this is an avalon block and not a cocoon block, and deploy 

[this could be done thru DOCTYPE reaction as well, but namespaces are a 
much cleaner way to do this]

IMO, that's the simplest solution that can possible work for both 

Because while deploying an avalon block in cocoon might make sense, 
deploying a cocoon block in merlin wouldn't make any sense at all.


View raw message