common meta model discussion revisited

[Leo Simons <le...@apache.org>]

All (Pete, Steve, Berin, others),

I have just reviewed the meta model discussion once again. Before
entering the issues of disagreement once more, let me do a recap of
stuff we agree upon, goals, definitions, etc.

Meta Model
----------
The meta model encompasses all information about a component that is not
specified by its work interface and/or lifecycle interfaces.
Specifically, the Meta Model allows for specification of
lifecycle-related constraints/requirments, ie Context, Configuration,
Parameter, and Dependency constraints/requirments.
Whether the Meta Model should allow for the specification of lifecycle
extension related constraints is subject of debate.

Meta Model API
--------------
The Meta Model API is a set of well-known interfaces and classes that
can be used to provide a runtime representation of the meta model.

Meta Model DTDs
---------------
The Meta Model DTDs are a set of well-known XML DTDs that provide a
mapping of the Meta Model API in XML.

Meta Model XML API
------------------
The Meta Model XML API provides an implementation of the Meta Model API
that takes XML documents following the Meta Model DTDs as source.

Design goals
------------
The Meta Model should be well-known to all avalonized applications.
Avalon Containers should share as much of a common meta model as
possible. It should be easy to implement support for the common meta
model in an Avalon Container.

The Meta Model should allow for easy extensibility to provide additional
container-specific functionality. It should be flexible to allow for
dynamic and/or runtime manageable ("hot-pluggable") containers to
function properly.

It should provide support for both hashed and hierarchical metadata.

Design constraints
------------------
The Meta Model should be restricted to the same problem domain as avalon
itself: it should be specifically about enabling COP. It should be small
in terms of code size, footprint, resource consumption, just like avalon
framework. It should be well-documented.

ECM is stable and phoenix is in beta. The meta model should provide as
much interoperability with / support for these projects as possible.

Target audience
---------------
The meta model should be such that it satisfies the needs of all current
Avalon Container user communities, specifically it needs to be
satisfactory to the requrments of cocoon, james, turbine, ant, ecm,
phoenix and merlin/fortress users (in no particular order), to the
maximum extent possible.

Existing work
-------------
Current containers defining a formal meta model to some extend are
phoenix, merlin and fortress. Work is also underway inside the excalibur
CVS to extract the reusable parts of this model inside (among others)
the containerkit and assembly packages.



can I get some +1s on these common goals and definitions?

If different people have different goals for the same project that would
explain some of the problems in working together on this effort...

cheers,

Leo


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: common meta model discussion revisited

[Stephen McConnell <mc...@apache.org>]

+1

good definition .. good scope


Leo Simons wrote:

>All (Pete, Steve, Berin, others),
>
>I have just reviewed the meta model discussion once again. Before
>entering the issues of disagreement once more, let me do a recap of
>stuff we agree upon, goals, definitions, etc.
>
>Meta Model
>----------
>The meta model encompasses all information about a component that is not
>specified by its work interface and/or lifecycle interfaces.
>Specifically, the Meta Model allows for specification of
>lifecycle-related constraints/requirments, ie Context, Configuration,
>Parameter, and Dependency constraints/requirments.
>Whether the Meta Model should allow for the specification of lifecycle
>extension related constraints is subject of debate.
>
>Meta Model API
>--------------
>The Meta Model API is a set of well-known interfaces and classes that
>can be used to provide a runtime representation of the meta model.
>
>Meta Model DTDs
>---------------
>The Meta Model DTDs are a set of well-known XML DTDs that provide a
>mapping of the Meta Model API in XML.
>
>Meta Model XML API
>------------------
>The Meta Model XML API provides an implementation of the Meta Model API
>that takes XML documents following the Meta Model DTDs as source.
>
>Design goals
>------------
>The Meta Model should be well-known to all avalonized applications.
>Avalon Containers should share as much of a common meta model as
>possible. It should be easy to implement support for the common meta
>model in an Avalon Container.
>
>The Meta Model should allow for easy extensibility to provide additional
>container-specific functionality. It should be flexible to allow for
>dynamic and/or runtime manageable ("hot-pluggable") containers to
>function properly.
>
>It should provide support for both hashed and hierarchical metadata.
>
>Design constraints
>------------------
>The Meta Model should be restricted to the same problem domain as avalon
>itself: it should be specifically about enabling COP. It should be small
>in terms of code size, footprint, resource consumption, just like avalon
>framework. It should be well-documented.
>
>ECM is stable and phoenix is in beta. The meta model should provide as
>much interoperability with / support for these projects as possible.
>
>Target audience
>---------------
>The meta model should be such that it satisfies the needs of all current
>Avalon Container user communities, specifically it needs to be
>satisfactory to the requrments of cocoon, james, turbine, ant, ecm,
>phoenix and merlin/fortress users (in no particular order), to the
>maximum extent possible.
>
>Existing work
>-------------
>Current containers defining a formal meta model to some extend are
>phoenix, merlin and fortress. Work is also underway inside the excalibur
>CVS to extract the reusable parts of this model inside (among others)
>the containerkit and assembly packages.
>
>
>
>can I get some +1s on these common goals and definitions?
>
>If different people have different goals for the same project that would
>explain some of the problems in working together on this effort...
>
>cheers,
>
>Leo
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>