Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 31617 invoked from network); 17 Aug 2002 05:51:25 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 17 Aug 2002 05:51:25 -0000 Received: (qmail 28312 invoked by uid 97); 17 Aug 2002 05:52:00 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 28260 invoked by uid 97); 17 Aug 2002 05:51:59 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 28248 invoked by uid 98); 17 Aug 2002 05:51:59 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <3D5DE451.9060700@apache.org> Date: Sat, 17 Aug 2002 07:51:13 +0200 From: Stephen McConnell User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Avalon Developers List Subject: Re: Why two component DTD? References: <017001c24599$f8bc0660$5eb2c4d3@nervous> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: For additional commands, e-mail: