Eung-ju Park wrote:
>Merlin and Phoenix have there's own DTD.
>
Correct.
The blockinfo DTD from Phoenix and the Avalon Meta Model DTD derived
from a fork of the original containerkit DTD and developed mainly as a
result of the Merlin project, operational trials, and list feedback.
The two DTDs are listed below.
http://cvs.apache.org/viewcvs/jakarta-avalon-phoenix/src/schema/blockinfo.dtd?rev=1.11
http://cvs.apache.org/viewcvs/jakarta-avalon-excalibur/assembly/src/java/org/apache/excalibur/meta/type.dtd?rev=1.2
>It's not good. I think they have no big difference.
>
There are serval differences:
BlockInfo defines:
* component info
* dependecies
* service offered
* management access points
Type defines:
* component info including attributes
* dependecies includeing attributes
* services including attributes
* logging catagories including attributes
* context dependecies (key and type) including attributes
* stage dependencies including attributes
* extension handler suppliers including attributes
>Evolution is better than forking. We will think more about merging each
>other's pros.
>
>
If you were to take the above DTDs and come up with a common DTD you
would end up with a variation of the Type DTD the was exteded to include
a management element. Given numerouse expresions of interest in Merlin
providing support for management services, and your suggestion, I have
gone ahead and included this feature into the base Type DTD.
Type now include:
* management access points
Which brings the type DTD totally in-line and consitent with the
existing practices in Merlin and Phoenix.
In terms of impact on containers, the current Avalon Meta Model (Merlin
and progressivly Fortress) impementation would need to handle (reject or
ignore) management access point declarations until implemetations are
provided, just as Phoenix would need to reject components declaring
lifestyle depedencies and lifecycle extension abilities until such time
that implementation support is provided, in addition, Phoeix can ignore
context, logging, and associated attributed until such time that an
implementation if considered a priority.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
