Re: Proposal for Simplifications to the Component Model

Amy, 

Thx for the review.

> 
> 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.

Programming languages are formal so, at implementation time, people are 
going to formalize the spec. Formal specification is not the end goal. 
It's like a early attempt at implementation. If we can't express the 
semantics of the spec formally, that's a red flag to me. It tells me that 
when people try to implement the spec, they will run into problems and the 
consequence will be poor interoperability and yet another WS-I profile. 

> 
> 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?

No, they could be in different documents. However, all the attributes and 
children of the two <interface> elements would have to be the same 
(possibly in a different order). You could copy and paste an <interface> 
into another document and it would be equivalent to the original.

What I am proposing is that equivalence be defined in terms of the 
infosets of the elements, not in terms of the component models. It is 
simple to define Infoset equivalence. It is trickier (and somewhat 
circular) to define Component equivalence.

> 
> 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.
> 

Organization Y has no right to tamper with the definitions created by 
organization X, but if they do, they must preserve the Infosets.

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

Yes, the simplification is more restrictive, but I don't think it has any 
practical impact. It just means that you NOT should use the same operation 
name in two interfaces if you expect someone to extend both of them. If 
you expect the interfaces to be extended, then you should move the common 
operations into a common base interface. Why duplicate the definition of 
the operations?

> 
> 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?

Yes, we can remove this capability now. No one is using it yet. The use 
cases we know about, e.g. from Grid, can be handled.

> 
> > 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.

Yes, this limits expressivity, but I don't think in a significant way. You 
just have to put common operations in a single interface and inherit from 
that. No automatic merging is allowed.

> 
> > 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.

I think this is neater. Components have a simple tree containment 
hierarchy instead of a graph structure.

> 
> > 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.

In view of your use cases for WS-Choreography, etc. I withdraw suggestion 
#3 and replace it with the addition of an {in-scope extensions} property 
to express the inherited extensions defined at the root level.

> 
> 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?

Yes, we should allow the <description> component to contain extension 
components.

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