RE: propagation of values in the component model

My 2c.

The WSDL component model does not collapse extended interfaces, but instead
retains the {extended interfaces} property in the component model, and
associates the {interface operations} and {interface faults} properties with
the separate interfaces instead of rolling them all together.  These seem
like they might be more similar to the {model reference} property than the
{style} and {http method} properties, which involve the processing of
*Default attributes.

Following this {interface operations} model, you would keep the annotations
where they are now - on the interface on which they were specified.  But
this doesn't seem to match your semantics very well.

Your semantics seem to be, that an interface that inherits from another
inherits not only the operations of that interface, but also any model
references that apply to the first interface.  At first blush that seems
backwards to me.  I would expect any annotations applying to an interface to
also apply to the interfaces it extends, but not vice versa.  Otherwise it
smells vaguely like a distant cousin of the dreaded chameleon include.

For instance, imagine an interface-wide safety property (and imagine that
makes sense too, which I'm not sure it does).

<interface name="a" s:modelReference="safeInteraction" extends="b">
<interface name="b" >

>From this I would conclude that all operations in interface a, whether
defined in a or inherited from b, are safe.

In the opposite case:

<interface name="a" extends="b">
<interface name="b" s:modelReference="safeInteraction">

It doesn't seem obvious that all the operations should be treated as safe,
as the author probably only meant that the operations defined in b are safe.

If the latter interpretation is what you want (probably not the status quo),
then keeping {model reference} separate for each operation (the status quo)
is good.  If you really want the former, it perhaps does make sense for a
{model reference} to be the union of model references specified on the
interface with any specified on extended interfaces, even though that's not
consistent with {interface operations}.

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
 

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
> Behalf Of Jacek Kopecky
> Sent: Wednesday, February 14, 2007 5:30 AM
> To: WS-Description WG
> Subject: propagation of values in the component model
> 
> 
> Dear all,
> 
> as you may be aware, SAWSDL defines a few annotation properties that
> apply to WSDL documents, for example modelReference (a set of URIs).
> SAWSDL also introduces the property {model reference} on the annotated
> WSDL components, e.g. on Interface components.
> 
> In some situations, the model references on some components apply also
> on other components, e.g. from an interface to another interface that
> extends the first one. The SAWSDL WG is about to discuss whether this
> propagation should manifest in the WSDL Component Model or not, i.e.
> whether the extending Interface component's {model reference} property
> should include the values of {model reference} from the extended
> Interface component(s) (values of {extended interfaces} property).
> 
> I note that the WSDL language itself goes both ways, in a sense:
>      1. The {style} property on Interface Operation gets its value
>         either from the operation element's style attribute, or from the
>         parent interface element's styleDefault attribute.
>      2. The {http method} property is only instantiated from the
>         whttp:method attribute, and it's up to the implementations of
>         the HTTP binding to use {http method default} in case {http
>         method} is missing.
> 
> The first approach means that a parser (if it's modeled after the
> component model) will do the value propagation and apps need not care
> whether style came from style="..." or styleDefault="...". However, this
> approach also has a problem when creating a WSDL and then serializing it
> into a WSDL file: the serializer must guess the styleDefault because it
> only knows the {style} values of all the operations.
> 
> The second approach requires that the propagation is done by the app,
> leaving space for error above the parser. But in the HTTP binding's case
> this is necessary, e.g. when an interfaceless binding is combined with
> some interface and the whttp:methodDefault applies. In fact the values
> were propagated before we noticed that this doesn't work for
> interfaceless bindings, can I therefore assume that it's in the spirit
> of the component model to propagate the values as much as possible?
> 
> Basically, I'd like to ask for any opinion on which way SAWSDL should go
> - should the component model implement all the propagation or should it
> more closely reflect the actual file, leaving the propagation rules to
> be implemented in the apps?
> 
> BTW, it is *not* my intention to say that WSDL is inconsistent in its
> behavior and should be fixed in any way.
> 
> Bets regards,
> Jacek

Received on Thursday, 15 February 2007 20:33:03 UTC