> >block: deprecated alias for component > > > Agree that deprecation as a term is possible. It was not the > only thing > called component though in the context of the Avalon project.
Yup. > >component: A passive entity that performs a specific role > > > > > Refer also to patterns to complete story. Hmm. I'd say the definition list should be self-contained, and The pattern documentation should refer to0 the definition list. > >consumption: the usage by a component of a service > > > -1 ... it is a new term. No term currently in use is satisfactory as pointed out by others in recent discussion. The goal here is to remove ambiguity and define one common set of terms for use throughout the project. > >entity: part of the computer hardware and/or software system > > > -1 .... over used. The term is used in many places throughout the docs and the code. Hence, we should provide a definition. The definition I chose matches the dictionary and fits current term usage. > >metadata: the complete set of specifications of component types, > >component profiles and service definitions > > > Personally I find the term 'metadata' and 'meta' too ambiguous. I'd > prefer to see 'Component Metadata'. The issue is when you consider service metadata where service is distinct from component. Current metadata proposals mix component and service metadata hence I feel component metadata is inappropriate. > >profile: the combination of the specification of resources > consumed by > >a component at runtime and the type applicable to the component > > > -1 ... it is a new term. The term is neccessary to completely define a component metadata model specification unambiguously. It is also already in use. > >provision: the supplying of a service implementation > > > -1 ... it is a new term. No term currently in use is satisfactory as pointed out by others in recent discussion. The goal here is to remove ambiguity and define one common set of terms for use throughout the project. > >resource: any entity or combination of entities > > > -1 ... it is a new term. And it is overused. The term is used in many places throughout the docs and the code. Hence, we should provide a definition. The definition I chose refers to another term and will enable people that wonder what we mean in our current documentation to better Understand the 'generalism' in use here. > >role: the key by which a service is referenced at runtime > > > Hoping for simplification to key. Hmm. I think just "key" is a little too generic; and it is in use in multiple places (it can also refer to a "key" inside a Context or Parameters object). A possibility is "service key", but since role has been in use for a long time I suggest we keep it. This is especially important as it is also in use directly inside a lot of client code in the form of <<classname>>.ROLE. > >type: the combination of a service specification and a dependency > >specification > > > -1 ... it is a new term. The term is neccessary to completely define a component metadata model specification unambiguously. It is also already in use. > >work interface: a java interface specifying component > functionality (as > >opposed to specifying component behaviour) > > > -1 ... it is a new term. The term is neccessary to completely define a component metadata model specification unambiguously. It is also already in use. I disagree with you on the notion that there are "new terms" introduced in the above list. All of them are in use in various software systems, and most of them already in use inside avalon, though perhaps not inside the avalon framework documentation. I would rather define more terms than will actually be used as opposed to defining only a few terms resulting in proliferation of author- or subproject-specific terminology (ie the current Situation). I would also rather define new terms than use inappropriate terms. I consider backwards compatibility in terminology to be not *that* much of an issue as we basically have very few terms neatly defined atm. Where it is possible to use existing terms we should do so, however. Oh, and sorry for sounding like a machine in the above post, but I figured this would be the most productive ;) cheers, Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
