Peter Royal wrote:
>On Sunday 18 August 2002 06:15 am, Stephen McConnell wrote:
>
>
>>Consider the following three DTDs:
>>
>>
>> type blockinfo containerkit
>>
>> name yes yes yes
>> version yes yes yes
>> component attributes yes no yes
>> services yes yes yes
>> service attributes yes no yes
>> depedencies yes yes yes
>> dependecy attributes yes no yes
>> context criteria yes no yes
>> context attributes yes no yes
>> stage depedenciers yes no no
>> stage attributes yes no no
>> extension declarations yes no no
>> extension attributes yes no no
>>
>>
>>Using the Type DTD you can define a component what can be validated by
>>any container. You can deploy that component in any container in the
>>knowlege that you will get a validation failure if you try to load
>>something that a container does not support. Support is a container
>>issue - interoperability is a subject of the DTD. The DTD is not bound
>>to the API.
>>
>>
>
>I think I may see pdonald's object to type support in Phoenix... *MAY*...
>
>Why support loading a DTD that is not fully utilized?
>
Support is a subject for a container.
The DTD emnabled the harmosizxation of teminaology, data descriptyion
formats, and supporting tools.
>If a component is
>cross-container, shouldn't it have the lowest-common-denominator DTD to
>enable full portability vs having a richer DTD and the possiblity of a
>container rejecting the component due to unsupported features?
>
If you take the lowest comon denominator approach, then each container
will end up defining digffernet extensions to the base DTD. This means
that you end up with containers puting in place maps between different
concepts - and basically hinders the development of interoperable
components. With the one DTD approach, there are elements that fall
into two categories: (a) quality-of-service (e.g. logging catagory
declarations), and (b) functional constraints (e.g. a service, context
or phase depedency). In the case of functional constraints, a container
does not need to provide implemetation support but as a minimum, it
should be recognizing what it cannot support.
>
>Ok, we modify Phoenix to read the Type DTD, but what good does that do us if
>all components that have that DTD use the features that Phoenix does not
>support?
>
It provides you with incentive to do something about it. Phoenix isn't
the benchmark - the benchmark is what the user wants to do.
>What benefit do those components get from the richer DTD if they do
>not utilize its features?
>
Benefits:
* The ability to use common developent tools.
* A consitent terminology
* Component validation in all containers.
>
>
>Is the DTD compatibility a red herring?
>
>
>imho, we need to resolve the 4 no's that exist between containerkit and type.
>
>Steve: I'm unsure of what the "extensions" are. Stage's are the lifecycle
>extensions, yes? If so how to extensions fit in?
>
The <stage/> element defines a dependency the component has on a
lifestyle stage extension.
The <extension/> element is the declaration that a component can provide
extension handling.
I.e. this is similar to the paired notion of dependencies and services.
See Merlin documentation on this:
http://home.osm.net/doc/merlin/extensions.html
>
>Pete: You describe some "hairy" problems
>(http://marc.theaimsgroup.com/?l=avalon-dev&m=102833233625631&w=2), but we
>can work through them, yes?
>
>Collectively we are a very smart bunch and can figure anything out.
>
>
>Any one final thought, PLUR
>(http://www.hyperreal.org/raves/spirit/plur/PLUR.html, to show my roots :) ..
>and it *is* apache related.. brian behlendorf started hyperreal..
>-pete
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
