Re: Proposal for Simplifications to the Component Model

Amy,


www-ws-desc-request@w3.org wrote on 01/28/2005 06:23:54 PM:

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

Based on our discussion of the requirement for top-level extension 
elements and attributes, I don't think infoset equivalence will work. The 
upshot is that we will have to live with the more complex concept of 
component equivalence. Here's the reason:

There are two kinds of extensions that you could put in the top level: 1) 
extension components, and 2) extension properties. An extension component 
would presumably to treated like Interface, Binding, Service, in the sense 
that it becomes something you could refer to, but its presence doesn't 
alter the semantics of the other components.

In constrast, an extension property is something that affects the other 
components, like a Feature or Property component does. I assume that you 
can put an extension property at the root and its presence might affect 
some of the other components, i.e. that those other components might 
acquire some {extension properties}. This is only implicit in Part 1.

Here's an example:

Document 1:
<description>
        <x:reliable/>
        <interface name="Register"/>
        <binding name="SOAPRegsiter"/>
</description>

Document 2:
<description>
        <interface name="Regsiter"/>
        <binding name="SOAPRegsiter"/>
</description>

Assume that the spec for <x:reliable> states that all Bindings described 
in the document are reliable, but the extension does not modify the 
semantics of any Interface or Service components.

Isn't it true then that the two Interface components are equivalent, but 
the two Binding components are not equivalent?

If you agree with the above, then we can't define equivalence at the 
infoset level. 



> 2. restrict interface inheritance such that it is an error to repeat an
> operation/fault definition

Yes, I'd still like to go with that restriction.

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

Yes. I think {in-scope features} and {in-scope properties} are cleaners. 
Also add {all operations} and {all faults} to distinguish those 
inheritance from those directly defined. These changes so not affect the 
expressiveness of the component model. They are really editorial.

{in-scope extensions} is probably not the right thing in light of the 
above. We need to be more precise. We are really taking about extension 
properties and extension components. We therfore need at least two more 
component properties, i.e. {extension components} and {extension 
properties}. And if we want to be consistent, we should have the in-scope 
flavours of these, i.e {in-scope extension components} and {in-scope 
extension properties} to allow for inheritance and combination of these.

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

I withdrew that proposal, but the <description> element is currently not 
allowed to have Feature and Property components. The component model does 
not have {features} and {properties} on the Definitions (aka Description) 
component.