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

Personally, I prefer when apps are small and there's a
higher-level 
interface. It's good to factor things out as much as you can
rather than 
duplicate.

As for WSDL itself, te issue was discussed previously [1]
and the status 
quo prevaled.

JJ.

[1] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.ht
ml#CR044

Jacek Kopecky wrote:
> 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  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  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
>
>
>   

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
 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://auburnmar
shes.spaces.live.com
 

> -----Original Message-----
> From: www-ws-desc-requestw3.org
[mailto:www-ws-desc-requestw3.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  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  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