Re: "operation name" .. an alternate proposal

Sanjiva Weerawarana wrote:

>"Umit Yalcinalp" <umit.yalcinalp@oracle.com> writes:
>  
>
>>In essence, your proposal requires utilizing the soap action feature, 
>>doesn't it?
>>
>>--umit
>>    
>>
>
>I didn't think an abstract concept without any binding would be
>of much use. Since we already have wsoap:action in our binding,
>I was proposing to map to that. However, I neglected to note that
>in order to do that properly we'd have to move wsoap:action
>to each message level rather than keeping it at the operation
>level:
>
>    <operation ref="xs:QName" 
>               wsoap:mep="xs:anyURI"? >
>      <documentation />?
>
>      <wsoap:module ... />*
>
>      <input messageLabel="xs:NCName"? wsoap:action="xs:anyURI"? >
>        <documentation />?
>        <wsoap:module ... />*
>        <feature ... />*
>        <property ... />*
>      </input>*
>
>      <output messageLabel="xs:NCName"? wsoap:action="xs:anyURI"? >
>        <documentation />?
>        <wsoap:module ... />*
>        <feature ... />*
>        <property ... />*
>      </output>*
>
>      <feature ... />*
>      <property ... />*
>    </operation>*
>
>IMO that makes perfect sense .. at least if you accept the rationale
>I gave for this proposal.
>
>Sanjiva.
>
>
>  
>
Sanjiva,

I think in essence we agree on the goal and the rationale. This is 
exactly what my proposal is trying to do, too and it is good to see that 
Phillipe is suggesting an amendement to yours based on my proposal 
utilizing fragment identifiers from Section C3 of our spec. ;-) [1] This 
is in essence what the Property with URI 
(http://www.w3.org/TR/wsdl20/features/operationName/Name) in my proposal 
is doing, capturing the value of the operation name as a URI with the 
fragment identifier.

However, here is my big problem with yours:

SOAP 1.2 Part2 specification indicates that SOAP Action feature is 
required to be supported by the HTTP binding  [2]. However, the action 
parameter is OPTIONAL per the same specification, A 3. See the following 
paragraph:

"Use of the action parameter is OPTIONAL. SOAP Receivers MAY use it as a 
hint to optimize processing, but SHOULD NOT require its presence in 
order to operate."

Therefore, your proposal makes the optional parameter required as it 
will require the wssoap:action attriibutes to appear. Since the 
OperationName feature is a required feature, this will force the 
OPTIONAL parameter to be REQUIRED for all cases.

I have a big problem with that. This is why I don't want to change the 
current semantics of SOAP 1.2 HTTP binding to require this optional 
parameter to be present as well as define what it is. It seems to be 
completely counter intuitive.

I checked the other portions of our spec. So far, it does not appear 
that we require the useage of wssoap:action, but we allow it to appear. 
This proposal as it is written puts an additional requirement to depend 
on it.

In my proposal, if there was a mandatory extension which even required 
the parameter to be present, that will be declared as such and WSDL 
processors would detect it. In yours, the required way to do is to use 
SOAP Action which makes the parameter required. Further, it is not clear 
whether other extensions can override it or not.

Cheers,

--umit

[1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0112.html
[2]  http://www.w3.org/TR/2003/REC-soap12-part2-20030624/
[3] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#ietf-action

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com