Component Model is Inconsistent wrt Interface Inheritance, Features & Properties, and Component Equivalence

I've run into a set of subtle, intertwined problems which are making it 
difficult to write a clear, simple, and consistent formal spec.

1. The spec describes a composition model for Features and Properties, but 
this is not reflected in the mapping of the infoset to the component 
model. The problem is that the {features} and {properties} of a component 
are not simply copied from the infoset. They must be computed using the 
composition model. This is an important point since the notion of 
equivalence of components is defined in terms of their properties. For 
example, If an interface extends interfaces A and B and each of A and B 
contains an operation X, then this is allowed as long as the operation X 
in A is equivalent to X in B. But to compute equivalence we need to look 
at the {features} and {properties} of X in each case. Suppose in A, X has 
a feature F defined, but in B, X is defined on B (not X). In this case X 
inherits F from B so the components are equivalent and the inheritanc is 
allowed even though the infosets for X in A is different than X in B.

2. The Features and Properties composition model does not specify what 
happens in the care of interface inheritance. The spec says the {features} 
and {properties} of an interface component are a superset of the 
{features} and {properties} of those of any interfaces it extends. 
However, this is not correct since the same Feature or Property may be 
defined differently in two extended interfaces, or may be explicitly 
defined in the new interface. We need to describe this situation. i.e. is 
it disallowed or do they combine in some way, or are they "overridden" by 
a definition in the interface.

I recommend that we modify the component model as follows:

The component model should make a distinction between properties that 
correspond directly to the infoset and properties that are derived. This 
is analogous to the notion of "in-scope" namespaces in the infoset. 
Specifically, we should augment the component model by adding {in-scope 
features} and {in-scope properties} in all components that have {features} 
and {properties}. We should also augment the Interface component with {all 
operations} and {all faults} which should be the sets of operations and 
faults that are either defined in the Interface or are inherited from 
Interfaces that are extended by the given Interface. {operations} and 
{faults} should be the components defined directly in the Interface.

In a similar spirit, I suggest that we model component references in terms 
of infoset values, e.g. QNames,  instead of abstract component references. 
The reason for this is that it would simplify the definition of component 
equivalence. For example, to compare two binding components we would 
compare the QNames of the interfaces they bind, and not descend into the 
the actual Interface components to determine if they were equivalent. It 
would be highly desirable if the notion of equivalence could be defined by 
looking at the infoset only and not the component model.

Finally, I suggest that equivalence use the infoset values of {features} 
and {properties} and not their in-scope values. This means that we can 
compute equivalence by just looking at the infoset of the component and 
not by examining the component model.

The motivation behind introducing the notion of equivalence was to allow 
the case of "diamond" inheritance, i.e. to have duplicate but "identical" 
definitions. The added complexity of defining equivalence in terms of the 
in-scope (i.e. composed) values of Features and Properties is not 
justified by any important use cases that I am aware of. Authors can 
always define components to have equivalent infosets when they are 
intended to be equivalent components.

Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
intranet: http://labweb.torolab.ibm.com/DRY6/