avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: {PROPOSAL] Standard location for the Avalon Component DTD
Date Mon, 08 Jul 2002 00:21:09 GMT

Peter Donald wrote:

>On Mon, 8 Jul 2002 09:40, Stephen McConnell wrote:
>>Peter Donald wrote:
>>>On Mon, 8 Jul 2002 03:04, Stephen McConnell wrote:
>>>>I would like to propose that the DTD for the <component-info/> structure
>>>>be included in the avalon-framework CVS and distribution jar in a
>>>>package named org.apache.avalon.framework.dtd.
>>>>   org/apache/avalon/framework/dtd/componentinfo.dtd  // latest version
>>>>   org/apache/avalon/framework/dtd/componentinfo_1_0.dtd  // version 1.0
>>>there is no universal descriptor yet.
>>Sorry - can you explain what you mean?  We are talking about several
>>projects using a versioned DTD to validate a <component-info/> root
>>element.  There is a containerkit implememtation and there is a
>>meta.info implemetation - both have internal references to what amounts
>>to the same DTD.  Wha't the problem with adding this to the framework?
>Currently the metainfo packages are different and incompatible. This is only 
>going to increase over time. 

The DTD for an external form of a <compoent-info/> declaration does not 
restrict you to the use of a particular meta model.  It is simply the 
criteria for model creation. Currently, the DTD used in containerkit is 
the same as the DTD used in the Merlin meta.info model. What I'm 
suggesting here is that components that are put in place to support the 
current *common* <component-info/> DTD should not be impacted by changes 
that are not formally introduced as new visions to the *common* defintion.

>If something needs to be changed I want to be 
>able to change it - not have to worry about you trying to block it or 
>anything similar. 

Pete - I'm not tryying to block anything you want to do.  I'm simply 
proposing that right now there is a DTD that is workable, validated, and 
is the same between the containerkit and the new meta.info model.  I 
think it would be desirable to place a copy of this current DTD in 
framework.  This does not stop you or I or anyone else from comming up 
with other variants (and the corresponding support).  But what it does 
do is enables a broader spectrum of users to start playing around and 
investing time in exploring what this is all about.  If these users see 
that we have at least as initial component info description format, we 
are likely to get a greater level of participation.  Naturally change to 
that reference DTD beyond documentation enhancements would be unlikely 
without a version increment.  So I don't see a blocking issue here. 
 Should you choose not to support a common version 1.0 DTD in 
containerkit - that's your business - but as far as I can see that's not 
something that is a question for vote. Does this clarify the proposal? 
 If not, could you explain to me how this proposal would enable me to 
block what your doing?



Stephen J. McConnell

digital products for a global economy

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message