Re: Proposal for Simplifications to the Component Model

Hmm, okay.

I'll wait to see how others feel about this, then.  The return of
extensions to the top-level resolves the major issue that I thought I
saw here.  I'll let those who feel more strongly about inheritance speak
out, and listen to the discussion, for now; I think we can probably live
with the stricter model proposed, but it's sufficiently pervasive, in
concept, that I'm hoping others will jump in with comments, positive or
negative.

Have these been given issue numbers?  If I understand correctly, we can
summarize these as:

1. replace component equivalence with infoset equivalence [is this just
for top-level elements?]
2. restrict interface inheritance such that it is an error to repeat an
operation/fault definition
3. add the properties {in-scope operations} {in-scope faults} {in-scope
features} and {in-scope properties}  [Question: would it make sense to
add {in-scope extensions}, or is that Pandora's box?]

Please correct my summaries, if I've misrepresented.

I also understand that you've withdrawn the original 3, summarized as:
Remove extensions, features, and properties from the content of the
description element.  More or less correct?

Amy!
On Fri, 28 Jan 2005 17:14:42 -0500
Arthur Ryman <ryman@ca.ibm.com> wrote:

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


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

Received on Friday, 28 January 2005 23:24:16 UTC