Re: Proposal for Simplifications to the Component Model

Amy,

Thx for the input. I just wanted to verify that there are use cases for 
top level extension elements.

If we allow top level extensions, then we really need to expand the 
treatment of extensions in the spec, which is probably a good idea anyway.

I think we need to include some additional semantics. For example, some 
top level extension are components which could be referenced by other 
components. Other extensions could be used to add properties to other 
components, like the semantics of Feature and Property components. If we 
allow these "inheritable" extensions, then we need to augment the 
component model with the concept of {in-scope extensions}.

Consider then following example:

Document A:

<description ...>
        <extension name="X" />
        <interface name="Y" />
</description>

Document B:

<description ..>
        <interface name="Z" />
</description>

Document C:

<description ..>
        <include A/>
        <include B/>
</description>

In the component model for C we need to "remember" that extension X is 
in-scope for interface Y but not for interface Z. This could be handled if 
we introduce an {in-scope extensions} property, and we require that the 
author of the specification for the extension define how the extension 
affects other components, i.e. whether it is in-scope for them.

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/



Amelia A Lewis <alewis@tibco.com> 
Sent by: www-ws-desc-request@w3.org
01/27/2005 11:24 AM

To
Arthur Ryman/Toronto/IBM@IBMCA
cc
www-ws-desc@w3.org
Subject
Re: Proposal for Simplifications to the Component Model







I'm going to have to take some time and look at this carefully, but one
item simply leaps out:

On Thu, 27 Jan 2005 03:11:56 -0500
Arthur Ryman <ryman@ca.ibm.com> wrote:
> 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.

This is a *big* hit to the extensibility model, and potentially disrupts
the work of the folk who are building on top of WSDL, such as BPEL and
WS-Choreo.  I believe that I've seen at least a couple additional
languages defined as extensions to WSDL at the root level.

The servicegroup extension is disallowed, and any similar
unifying/correlating extension is as well (unless you take the
less-comprehensible path of sticking this stuff inside the bits that
they are supposedly related to in some fashion).

No, no, no.  This is a *major* change to the extensibility model.

> One other pleasant consequence of this rule is that we can have a 
> deterministic schema that enforces the order of the top level
> elements,  i.e.:
> 
> description =
>         (import | include) *
>         types ?
>         (interface | binding | service) *

That's rather nice, but it's not sufficient, in my view, to trump the
breakage it causes for BPEL and the like.

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