Why two component DTD?

[Eung-ju Park <co...@apache.org>]

Merlin and Phoenix have there's own DTD. It's not good. I think they have no
big difference.

Evolution is better than forking. We will think more about merging each
other's pros.


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

Re: Why two component DTD?

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

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:mcconnell@osm.net
http://www.osm.net




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