cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <>
Subject Re: block perspectives
Date Wed, 01 Oct 2003 14:22:48 GMT

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.

>  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.

>  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.  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.

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

> 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.

Cheers, Steve.


Stephen J. McConnell

View raw message