Folks, this is an important issue, and I would like more feedback from someone other than Stephen and myself.
I would like us to all standardize on one library to represent the metainfo, which also has some implications on the AMTAGS proposal as it stands. We have a proposal and a counter-proposal on the table, and we need to come to consensus on the final verdict.
Proposal:
* add a new tag, @avalon.type, with the attributes "name", "version", and "lifestyle" * add a new semantic for the @avalon.service tag, so that when it is declared in an interface the "type" attribute is not needed any more.
Counter-Proposal:
* Extend the @avalon.component tag with the attributes "name", "version", and "lifestyle", providing reasonable default values. * add a new semantic for the @avalon.service tag, so that when it is declared in an interface the "type" attribute is not needed any more.
The only real difference between the two proposals are the use of @avalon.type vs. @avalon.component. Both sides have valid points, but in the end it boils down to what the community as a whole would rather see.
@avalon.type Pro | Con ----------------------------------+------------------------------------------- 1) No overloading of an existing | 1) Forces deprecation of existing tag tag. | 2) Required attributes are more | easily enforced. |
@avalon.component Pro | Con ----------------------------------+------------------------------------------- 1) No cruft from deprecated tags. | 1) Defaults can often times cause | questions to how things should work.
VOTE:
THis is an exclusive vote. If you vote +1 for one approach, then that implies -1 for the other approach. No -1s are vetoes.
Use @avalon.type or @avalon.component?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
