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

> -----Original Message-----
> From: Umit Yalcinalp [mailto:umit.yalcinalp@oracle.com]
> Sent: Tuesday, February 24, 2004 11:38 AM
> To: Glen Daniels
> Cc: Jonathan Marsh; www-ws-desc@w3.org
> Subject: Re: 2004-02-12 Action Item: Clarification to the
OperationName
> feature

> 		1) Whether the operation name itself must appear in the
> message.
> 
> 
> 
> 	Not as such, no.
> 
> Jonathan, I am assuming what we are referring to as "message" is the
> soap:body, not envelope, namely the element references (GED)s, right?

No, I meant anywhere in the envelope.  One of your proposals was to
transmit the OperationName in a header, another is in the soap:action,
neither of which is in the soap:body.

> It only appears in the message as a side effect of using RPC style,
due to
> the definition of the RPC style only if you are using RPC style. This
is
> NOT an additional requirement brought by the feature, it just happens
> because one uses RPC style. The proposal indicates this.

Yes, I understand this, though Glen has new concerns on whether the GED
under RPC style still might not be unique.


> 		3) How a service that simply used unique GEDs for each
> 		message would interact with this feature.
> 
> 	You *could* state that the "default" implementation of the
feature
> is to
> 	simply map unique GEDs to their operation names, and then it
would
> only be a
> 	problem if you a) didn't find anything else in the WSDL (a SOAP
> module /
> 	binding) which implemented the feature AND b) there were in fact
> duplicate
> 	or undefined GEDs.  I would prefer an approach which forces the
WSDL
> 	developer to somehow explicitly assert (via a style or a feature
> 	declaration) the claim that all the relevant GEDs are unique.
This
> is kind
> 	of the same reason we have the RPC style - you *could* figure it
out
> on your
> 	own by just looking at the schema, but the style helps you
decide up
> front
> 	how you want to deal, and whether to bother engaging potentially
> expensive
> 	checks.
> 
> 
> +1.

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.

> Everything in the contract must be explicitly stated, if we would like
it
> to be interoperable.
> 
> 
> 
> 
> 		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?

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

> 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 assumption that a required
feature, when no corresponding implementation feature can be found,
results in a bad WSDL.  There also appears to be an assumption that a
required feature may interact, or override, the corresponding
implementation feature.

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.

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     |  ?     ?
  required        absent      |  ?     ?
  present         required    |  OK    Messages       contain
soap:action
  present         present     |  OK    Messages may   contain
soap:action
  present         absent      |  OK    ?
  absent          required    |  OK    Messages       contain
soap:action
  absent          present     |  OK    Messages may   contain
soap:action
  absent          absent      |  OK    Messages don't contain
soap:action

Received on Tuesday, 24 February 2004 19:20:09 UTC