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

It seems that my email created quite a lot of discussion. ;-)

Jonathan Marsh wrote:

>Below:
>
>  
>
>>-----Original Message-----
>>From: Glen Daniels [mailto:gdaniels@sonicsoftware.com]
>>Sent: Sunday, February 22, 2004 10:24 AM
>>To: Jonathan Marsh
>>Cc: www-ws-desc@w3.org
>>Subject: Re: 2004-02-12 Action Item: Clarification to the
>>    
>>
>OperationName
>  
>
>>feature
>>
>>Hi folks:
>>
>>(sorry about replying up here instead of inline, but I can't seem to
>>    
>>
>get
>  
>
>>Outlook Express to prefix quoted text with ">" in some cases (when
>>    
>>
>Outlook
>  
>
>>was used to send the original message, it seems) even though I have
>>    
>>
>all
>  
>
>>the
>>right switches set - grrrrrrrrrrrrr!!!  If you have a clue how to do
>>    
>>
>this,
>  
>
>>let me know!)
>>    
>>
>
>[This is probably not an optimal solution, but you can open the message,
>select Edit/Edit Message then Format/Plain Text.  Then Reply All and
>you'll get a plain text message with the line prefix.  (Sad in this day
>and age that plain text is still the lowest common demoninator...)]
>
>  
>
>>Having the operation name available somehow, no matter how, on the
>>receiving
>>end is precisely what we are trying to define with this feature.  It
>>    
>>
>does
>  
>
>>not need to be in the message content per se, and might also be
>>    
>>
>available
>  
>
>>via the URL, the action parameter, etc.  The only trick is that
>>    
>>
>something
>  
>
>>has to know how it is being done, and that must be somehow expressed
>>    
>>
>in
>  
>
>>the
>>WSDL.
>>    
>>
>
>I don't see a lot of difference in practice between "not expressed in
>the WSDL" and "expressed through an extension unknown to the processor."
>I don't see how you can meaningfully constrain the presence of the
>feature without also prescribing the sets of mechanisms for implementing
>it.  Otherwise there are loopholes you can drive a medium-sized asteroid
>through, which is where my examples are leading.
>  
>
We are expressing two distinct way of implementing it. There  may be 
different ways of implementing the feature, but I expect those that we 
specify will be the interoperable ways of using the feature. See my note 
that started this discussion [1]. This is why it is essential that the 
WSDL specification specifies concrete implementaions and how they will 
exhibit themselves in the WSDL document as specified by my note that 
started this thread.


>  
>
>>Making it a required feature, modulo precise wording tweaks, should
>>    
>>
>have
>  
>
>>the
>>same effect as if a <feature
>>uri="http://www.w3.org/TR/wsdl20/features/operationName"
>>    
>>
>required="true"/>
>  
>
>>were always present in the WSDL.  Umit suggests this should be in the
>><binding>, but I think it makes more sense to think of it in the
>><interface>.  Really doesn't matter though as long as it's always
>>    
>>
>assumed
>  
>
>>to
>>be there.
>>
>>I don't think that you can "widen" a required feature to optional, so
>>having
>>the required="false" as you suggest below wouldn't have any effect.
>>    
>>
>
>Does the spec say that somewhere?
>
We are proposing that the feature to be ALWAYS required. Hence having 
the switch should not have any effect.

>
>  
>
>>If you specify your "stick-operation-name-in-a-header" module without
>>noting
>>that it implements the operationName feature, then you haven't
>>    
>>
>satisfied
>  
>
>>the
>>operationName feature.
>>    
>>
>
>So, my WSDL is non-conformant because the spec writer didn't write his
>spec according to your guidelines?  Even in this case where the messages
>conform to the spirit of the feature?
>  
>
We are specifying a stick-operation-name-in-a-header module anyway. So, 
the WSDL writer HAS the choice to use it. Therefore, I don't understand 
why someone needs to specify yet another module to do the same thing. By 
providing implementations, we are guiding the folks into interoperable 
ways of implementing this. We are silent about the bindings we don't 
know about, and hence the implementation of the feature for 
bindings/transports we don't know about can not be specified.

>  
>
>>I'm not sure what the "obvious semantics" are in your "override"
>>    
>>
>example,
>  
>
>>actually. :)  Could you expand on that a little?
>>    
>>
>
>A better example:
>
> 
><my:put-no-operation-name-in-the-message-even-though-the-OperationName-f
>eature-says-you-have-to wsdl:required="true"/>
>
>This feature conflicts with the OperationName feature, and its spec
>probably says that it takes precedence over the OperationName feature.
>Is that an allowable composition with a "built-in" feature?  These are
>the kinds of questions we have to answer if we introduce built-in
>features as a new concept.
>  
>
It is not an allowable composition with the built in feature. However, I 
should point out that your example is similar to any extension that one 
can put into their WSDL specification and introduce something 
contradictory to what is defined in the WSDL specification. For 
example,  one were to define an extension to require an IN MEP to ALWAYS 
send a response, it would not be conformant to the specification, would 
it? This is not different, IMO.

--umit

[1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0082.html

>  
>
>>--Glen
>>
>>----- Original Message -----
>>From: "Jonathan Marsh" <jmarsh@microsoft.com>
>>To: "Umit Yalcinalp" <umit.yalcinalp@oracle.com>; "WS Description
>>    
>>
>List"
>  
>
>><www-ws-desc@w3.org>
>>Sent: Friday, February 20, 2    004 7:42 PM
>>Subject: RE: 2004-02-12 Action Item: Clarification to the
>>    
>>
>OperationName
>  
>
>>feature
>>
>>
>>
>>I'm not sure whether having the Operation Name in the message is
>>    
>>
>always
>  
>
>>necessary, but putting that aside - what are the implications of a
>>"required
>>feature"?  Is the WSDL somehow invalid if it specifies:
>>
>>  <feature uri="http://www.w3.org/TR/wsdl20/features/operationName"
>>required="false"/>
>>
>>?
>>
>>Suppose my binding for an operation named for instance "Fred" has an
>>extension
>>
>>  <my:stick-operation-name-in-a-header wsdl:required="true"/>
>>
>>with the obvious semantics, but whose specification doesn't tie this
>>behavior in with the OpName feature URI.  How will you know whether
>>    
>>
>the
>  
>
>>feature as been implemented?
>>
>>What if I introduce an extension
>>
>>  <my:override-operation-name-feature wsdl:required="true"/>
>>
>>With the obvious semantics.  Is this type of extension disallowed?
>>
>>"Required feature" is a new idea and I'd like to see more details of
>>    
>>
>what
>  
>
>>you expect to happen.
>>
>>
>>___________________________________
>>From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
>>    
>>
>On
>  
>
>>Behalf Of Umit Yalcinalp
>>Sent: Friday, February 20, 2004 3:28 PM
>>To: WS Description List
>>Subject: 2004-02-12 Action Item: Clarification to the OperationName
>>feature
>>
>>Folks,
>>
>>I was given an action item [1] to clarify the usage of OperationName
>>feature
>>[2], to clarify what is required and what must be specified in WSDL.
>>
>>Addendum to the Proposal:
>>
>>OperationName feature is a required feature for all WSDL descriptions.
>>    
>>
>It
>  
>
>>is
>>not specific to a binding since all bindings must implement this
>>    
>>
>feature.
>  
>
>>Therefore, the feature is not required to be declared as shown below
>>    
>>
>as it
>  
>
>>is assumed to be present in all descriptions:
>>
>><binding>
>>...
>><feature uri="http://www.w3.org/TR/wsdl20/features/operationName"
>>required="true"/>
>></binding>
>>
>>Note: This syntax may change per compositor syntax proposal [3].
>>
>>There may be multiple ways to implement this feature. The proposal
>>specifies
>>a distinct method for implementing this feature by using a soap module
>>    
>>
>for
>  
>
>>SOAP bindings. When the soap module specified by [2] is used as the
>>implementation method, its use must be declared in WSDL as follows:
>>
>><binding>
>>...
>><wsoap:module
>>    
>>
>uri="http://www.w3.org/TR/wsdl20/OperationDispatchModule"
>  
>
>>required="true"/>
>></binding>
>>
>>Note: The original proposal did not specify a URI for the SOAP module
>>    
>>
>that
>  
>
>>has been specified here.
>>
>>The SOAP Action feature may also be engaged in the binding in addition
>>    
>>
>to
>  
>
>>the OperationName feature as shown below:
>>
>><binding>
>>...
>><feature uri="http://www.w3.org/2003/05/soap/features/action/"/>
>></binding>
>>
>>In this case, the OperationName feature also specifies the value of
>>    
>>
>the
>  
>
>>SOAP
>>Action property as discussed in [2].
>>
>>--umit
>>
>>
>>[1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0076.html
>>[2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0082.html
>>[3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0153.html
>>
>>--
>>Umit Yalcinalp
>>Consulting Member of Technical Staff
>>ORACLE
>>Phone: +1 650 607 6154
>>Email: umit.yalcinalp@oracle.com
>>
>>    
>>
>
>
>  
>

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

Received on Monday, 23 February 2004 14:26:08 UTC