W3C home > Mailing lists > Public > public-ws-semann@w3.org > February 2007

Re: [Fwd: RE: propagation of values in the component model] - contribution and regrets

From: Laurent Henocque <laurent.henocque@gmail.com>
Date: Tue, 27 Feb 2007 16:30:28 +0100
Message-ID: <45E44E94.1070601@gmail.com>
To: Jacek Kopecky <jacek.kopecky@deri.org>
CC: SAWSDL public list <public-ws-semann@w3.org>

Hi all,
as a contribution to this topic, and considering the fact that I won't
be able to attend tonight's telcon because I am leaving now, I would
like to say that I disagree with the statements below. We are not
dealing with inheritance, and we have never made the least assumption
about the underlying semantics of model references. So neither can we
say that "b" is safe when "a" is, or the opposite.

I would suggest that the implementors of model references may decide
that some propagate, and others not, whichever way, and that this is
beyond our scope. All we say is that "all apply", meaning that anyone
can add any model reference anywhere with the intended meaning.

In the example below, the implementor of "a" operates in a context when
"b" is known already (since "a" extends "b"). Hence, if something
applies to "b", it can be mentioned on "b", and does not require back
propagating from "a" (sorry I still believe that inheritance based
propagation goes from the general to the specific).

So I vote for dropping any decision regarding propagation from the spec,
in favor of comments saying that such behaviors may occur but remain
implementation specific.


Jacek Kopecky a écrit :
> Hi all, below are some very interesting points about our model reference
> propagation. We will discuss it on Tuesday.
> Jacek
> -------- Forwarded Message --------
> From: Jonathan Marsh <jonathan@wso2.com>
> To: 'Jacek Kopecky' <jacek.kopecky@deri.org>, 'WS-Description WG'
> <www-ws-desc@w3.org>
> Subject: RE: propagation of values in the component model
> Date: Thu, 15 Feb 2007 12:32:58 -0800
> 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

Laurent Henocque
Maître de Conférences Hdr / Associate Professor
Ecole Supérieure d'Ingénieurs de Luminy - Marseille
Laboratoire des Sciences de l'Information et des Systèmes - Marseille
tel: +33 6 83 88 20 01

Clé publique open pgp / open pgp public key:
Received on Tuesday, 27 February 2007 15:30:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:19 UTC