Re: Proposal for Simplifications to the Component Model

Okay, some additional comments, now that I've had time to look through
this.

I think, on the whole, that we may simply be in trouble attempting to
formalize after the fact, rather than a) building a spec from a formal
definition in the first place (years too late, I'm afraid) or b)
admitting that parts of the specification cannot be formally described.

On Thu, 27 Jan 2005 03:11:56 -0500
Arthur Ryman <ryman@ca.ibm.com> wrote:
> 1. The spec has the notion of component equivalence. This concept was 
> introduced as a consequence of interface inheritance. The problem was
> that  we wanted to allow diamond inheritance, eg:

[snip]

> I'd like to propose a simplification. We should eliminate the concept
> of  component equivalence and use infoset equivalence instead. In a
> sense, the 

> The impact of this change is that as we are building up the component 
> model, we check to see that duplicate definitions of components have 
> equivalent infosets. If the infosets differ then we have an error and
> we  can't create the component model. The infoset definition is
> strictly  bottom-up and can be computed without reference to derived
> component model  properties.

I wonder if this can work.  Using infoset, wouldn't two interfaces that
extend interface "D" have to refer to the same document, where D is
defined?

If operations and faults are scoped, it isn't too difficult to imagine a
situation in which two equivalent definitions (by the component
equivalence method) of D, located in different documents, become two
separate interfaces, by infoset-equivalence testing.

This breaks interface inheritance, I suspect.  Suppose organization X
publishes interface D, and organization Y publishes the same thing,
slightly refactored but intended to have the same semantics but be
easier to understand, and extends it with C.  Organization Z now
publishes an extension of interface D that references the original
document.  Organization H (for "Houston, we have a problem") can't, I
think, publish a unifying interface, A, that extends B and C, under the
infoset equivalence model, but can with a component equivalence model.

Does this simplification also straiten/make stricter the rules?  Can we
do so, at this stage?

I don't want to underestimate the importance of a formal description, or
the difficulty of defining such a thing when recursion more or less runs
in both directions at once, but ... can we really remove this level of
descriptive capability?

> 2. An implication of the above proposal is that we would disallow 
> "accidental" duplication of operations or faults. For example, the 
> following situation is disallowed:
> 
> interface A { operation X };
> interface B extends A { operation X};
> 
> The above is disallowed since operation X is defined in two different 
> interfaces. This is disallowed even if the contents of operation (A/X)
> is  identical to operation (B/X). The appearance of X in B is
> considered to be  an accident and an error.

Ah.  Then I believe my interpretation of infoset equivalence above is
also correct.  And we've significantly limited the expressivity of the
inheritance mechanism.

> An additional motivation for this rule is that now all components have
> 
> unique URI's. Everyone component is defined in a unique parent
> component 

Not that persuasive a motivation, from where I sit.

> nsuri#wsdl.operation(B/X). And we would really have to compute its
> derived  properties to determine equivalence.

The status quo, no?

> 3. Finally, for this to work, we should only permit extension elements
> and  attributes in the top level elements: interface, binding, and
> service.  This means they are disallowed as children of the root
> description  element.

I mentioned reservations with respect to this earlier.  I think the
{in-scope extensions} suggestion is perfectly reasonable, but if others
have comments on that, it would be nice to hear them.

It seems that another possible solution might be to adjust the meaning
of the definitions component, no?  If that component could contain other
definitions, rather than containing the contents of those definitions,
would this not address some of the problems with scoped elements of any
sort?

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Friday, 28 January 2005 17:19:10 UTC