On Wednesday, Oct 1, 2003, at 16:22 Europe/Rome, Stephen McConnell wrote:
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.
ok
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.
http://avalon.apache.org/merlin/meta/block/index.html
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="http://apache.org/avalon/merlin/block/1.0";> ... </container>
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 accordingly.
[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 worlds.
Because while deploying an avalon block in cocoon might make sense, deploying a cocoon block in merlin wouldn't make any sense at all.
-- Stefano.
