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
>>>>
>>>>Thoughts?
>>>>
>>>>
>>>-1
>>>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?
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]>
