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

RE: propagation of values in the component model

From: Jonathan Marsh <jonathan@wso2.com>
Date: Tue, 29 May 2007 10:47:55 -0700
To: "'Jacek Kopecky'" <jacek.kopecky@deri.org>
Cc: "'sawsdl comments'" <public-ws-semann-comments@w3.org>
Message-ID: <024e01c7a219$7d13f310$773bd930$@com>

Yes, I'm satisfied, thank you!

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

> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek.kopecky@deri.org]
> Sent: Tuesday, May 29, 2007 10:08 AM
> To: Jonathan Marsh
> Cc: sawsdl comments
> Subject: RE: propagation of values in the component model
> 
> Hi Jonathan,
> in the email below, you raised the issue of whether SAWSDL should
> propagate {model reference} from extended interfaces to the extending
> one. We logged this as issue 8 in our issues list [1] and in our
> resolution, we agreed that model reference propagation may not quite be
> correct for interface extension. Therefore we resolved to remove this
> propagation, and this is implemented in the editor's draft [2].
> 
> On a related topic, we have clarified in SAWSDL how model references
> and
> schema mappings *are* propagated from type definitions to element
> declarations (and attribute declarations) that use those types. Since
> all the information is basically static in the descriptions, and
> because
> element declarations only give concrete element names to types, it
> makes
> sense to do the propagation in the component model, rather than to
> leave
> it to the applications.
> 
> Please respond to this message on whether you find this resolution
> satisfactory, so we can track your consent.
> 
> Thank you for spotting the problem,
> Jacek
> 
> [1] http://www.w3.org/2002/ws/sawsdl/issues/CR-20070126
> [2] http://www.w3.org/2002/ws/sawsdl/spec/SAWSDL.html
> 
> On Thu, 2007-02-15 at 12:32 -0800, Jonathan Marsh wrote:
> > 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 Tuesday, 29 May 2007 17:48:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:13 GMT