Paul Hammant wrote:
>> [...] The API is not defined by the DTD. Please - let's focus on
>> one layer at a time and keep the discussion cleanly focussed on the
>> issues at hand.
>>
>> The objective is one DTD that address all of the requirements - not
>> just yours.
>
>
> With respect, if the DTD allows elements and attributes that Phoenix
> cannot use, then there is a possibility that the block developer might
> avail of those features and thus, yes it is part of the API.
> - Paul
Correction.
If you go back over the Phoenix sources (CVS history) - you will find
examples of code that enables the creation of a BlockInfo class for
multiple DTD. The same thing exists inside Merlin - Merlin can read in a
blockinfo, containerkit or type DTD and generate its own internal Type
meta-info instance. The DTD is simply an external form - it does not
define the API - it defines data elements.
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.
Merlin and Fortress componets use extensions. These extensions need to
be declare either programatically or through a .xinfo descriptor.
* should a componet be defined relative to a specific container ?
- NO
* should a component be defined relative to a common componet defintion
- YES
* should that defintion support required versus optional elements
- YES
* should a container be aware of and deal with optional elements
- YES
* should the development of service and compoent management be
restricted to
a single container model such as Merlin
- NO
* should the development of service and compoent management be
restricted to
a single container model such as Phoenix
- NO
* should the development of service and compoent management be
restricted to
a single container model such as Fortress
- NO
* should the development of service and compoent management attempt
to aggregate
established and vaidated features across the set of Avalon containers
- YES
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
