RE: 2004-02-12 Action Item: Clarification to the OperationName feature

Thanks for your responses.  I think many of them need to be incorporated
into the OperationName proposal, though some might need to go into the
Part 1 spec.  Minor comments inline below.

> -----Original Message-----
> From: Glen Daniels [mailto:gdaniels@sonicsoftware.com]
> Sent: Wednesday, February 25, 2004 8:26 AM
> To: Jonathan Marsh; Umit Yalcinalp
> Cc: www-ws-desc@w3.org
> Subject: Re: 2004-02-12 Action Item: Clarification to the
OperationName
> feature
> 
> Hi folks:
> 
> >> [description of using unique GEDs to map to operation names]
> >
> > This fits nicely into my concept of a style, less nicely into my
> > concept of a feature declaration.  This is reflected in the
component
> > model - a style would not change the mapping to the component model,
> > a built-in feature would.
> 
> Does the style attribute exist in the component model somewhere?  I
would
> think it would have to.  Assuming yes, then I don't see much
difference
> between another style URI and another feature URI.  As long as either
one
> can be used to confirm that the OName feature has been satisfied,
we're
> good.

Yes, the style attribute value is reflected in the component model.
I'll leave it up to others whether they want to propose such a style.

> >> 4) What is the implication of a built-in required
> > feature on
> >> the syntax and the component model.
> >>
> >> No impact on the syntax, and the component model gets a single
> >> required
> >> feature component which is always assumed to be there, I think.
> >>
> >> That is what the clarification indicated. The implications on the
> >> syntax are
> >>
> >> -- none (for declaring the feature, because it is equivalent to be
> >> declared to be "always present" as if it was declared to be
required)
> >
> > The syntax might change (syntactic validity might be affected),
> > depending on how you choose to specify the processing of
<wsdl:feature
> > uri="...OperationName" required="false"/>, which is currently
allowed
> > in the syntax.  I'd think a concrete proposal on this would be
> > valuable. Is this particular element an error, silently ignored, or
> > result in duplicate feature components?
> >
> > Which uncovers an issue; currently the component model for...
> >
> >   <wsdl:interface>
> >     <wsdl:feature uri="myURI" required="true"/>
> >     <wsdl:feature uri="myURI" required="false"/>
> >   </wsdl:interface>
> >
> > ... would have two conflicting (I assume) feature components.  What
is
> > the meaning of such conflicting components?  Should the syntax or
the
> > mapping prevent such conflicts?
> 
> I don't think there's a conflict, but I think you're right, we need to
> specify this, and a few other things besides (i.e. how features +
> properties
> combine when specified in the interface/operation/binding).
> 
> IMHO, the above should be allowed and would have the same effect as if
> there
> were just the required="true" version.

I'll add this as a new issue.  I thought we already had some text in our
edtodo about combining properties at different levels.  If not, I hope
the editors will let us know!

> >> -- for bindings, the implementations will need to be declared as
soap
> >> modules, etc.
> >
> > Glen said I could use ESP.  I'm not sure whether you include that in
> > the "etc."
> 
> To be clear - I said you could use ESP as long as you had a feature
URI
> for
> it, and accepted the fact that if someone you were talking to didn't
> understand ESP, they were out of luck.

The OName proposal should say exactly what "out of luck" means.

> >> As stated above, this is a good thing IMO, because looking
> >> at the WSDL, it is obvious to infer the implementations that are
> >> engaged.
> >
> > I'm not sure what is obvious here, part of my ignorance of features
> > and properties is showing.  There are two things that could be
> > influenced by a feature - whether the WSDL should be rejected by a
> > processor, and what appears on the wire.  There appears to be an
> 
> Actually, that's the wonder of extensibility - features can actually
> influence whatever they want, in a very similar way to that of SOAP
> headers.
> If I see a recognized feature in the WSDL, and I know that the meaning
of
> that feature is "I agree to let the messages that flow between us be
> published in the New York Times", then I might not see any difference
at
> all
> on the wire when using this service and one which does not specify
such a
> feature.  However my expectations of seeing my message on tomorrow's
front
> page certainly would be affected.
> 
> > assumption that a required feature, when no corresponding
> > implementation feature can be found, results in a bad WSDL.  There
> 
> Correct, although not all features actually need an implementation per
se
> (some might be self-contained).

This concept isn't in the core spec.  I assume it needs to be detailed
in each feature spec that interacts with other properties.  In
particular, the OName proposal needs to be clear about what it means.

> > also appears to be an assumption that a required feature may
> > interact, or override, the corresponding implementation feature.
> 
> I'm not sure what you mean by this last bit.
> 
> > The concept of relating two features (abstract and implementation)
is
> > not supported by the WSDL spec, and not detailed in the
OperationName
> > proposal.  The precise outcomes (for the WSDL processor and for the
> > messages on the wire) need to be detailed.
> 
> The relationship between features is up to the feature specification
> writers
> and to the user of the WSDL, just as the relationship between SOAP
headers
> is up to the module specification writers and the user of the SOAP
> envelope.
> 
> > For instance, let me create a matrix of options, using the
> > OperationName feature (pretending it's not built-in) and soap:action
> > module as examples.
> >
> >   OperationName   SOAPAction  |  WSDL  Behavior
> >   Feature         feature     |
> >   ----------------------------------------------------
> >   required        required    |  OK    Messages       contain
> > soap:action
> >   required        present     |  ?     ?
> 
> In this case the availability of the SOAPAction feature (by which I'm
> assuming you mean the operation dispatch SOAP action feature that we
> proposed, not the generic one in SOAP 1.2) means that the processor
can
> choose to use it to satisfy the OName feature if desired.  If it's the
> only
> way indicated, then the action parameter will hold the operation info
in
> messages.  If there is another way as well, it might use either.  To
be
> clear, when you say "contain soap:action" here, you mean that the
> operation
> info is carried in the action parameter.

Also needs to go into the OName spec.

> The WSDL is OK for a given processor if there is an implementation
(either
> required or optional) of the OName feature which that processor
> understands
> in the context it is dealing with.  So if I say in a given service
"you
> can
> either do the SOAPAction thing or the SOAP header thing, but neither
are
> themselves required" (this would generally be a "pick one"), then as a
> client you're fine if you do either of those things.  As a server
> implementing this WSDL, however, you're going to have to do both,
since
> you
> won't know which one a given client is going to pick.
> 
> This is equivalent to making statements about other extensions, like
> security policy.  If a WSDL says you can use either username/pw or
x.509
> certificates, and you want to implement that WSDL as a service
provider,
> you
> need to support both.
> 
> >   required        absent      |  ?     ?
> 
> If there is nothing else in the WSDL (i.e. the OName module, RPC
style...)
> which satisfies the feature, you can't process the WSDL.

Exactly what "can't process the WSDL" means needs to be specified by the
OName proposal.  I don't think you intend to prevent the component model
from being constructed.

IMHO this is still a strike against the proposal.  I can construct a
WSDL that doesn't have any ambiguity in dispatching messages (e.g.
there's only one operation!) but I still can't process the WSDL without
being able to detect an assertion that this is true.
 
> >   present         required    |  OK    Messages       contain
> > soap:action
> >   present         present     |  OK    Messages may   contain
> > soap:action
> >   present         absent      |  OK    ?
> 
> In this case, your message aren't likely to contain the operation info
in
> the action parameter.
> 
> >   absent          required    |  OK    Messages       contain
> > soap:action
> >   absent          present     |  OK    Messages may   contain
> > soap:action
> >   absent          absent      |  OK    Messages don't contain
> > soap:action
> 
> --Glen

Received on Wednesday, 25 February 2004 14:38:04 UTC