Re: WSDL 2.0 operation safety annotation in SAWSDL?

Jacek, Jonathan,

The TAG discussed the questions that you raise below at our meeting 
yesterday (26-Feb). Draft minutes of that meeting are available at [1].

In summary, the TAG could not find an overriding architectural principle 
that enabled the TAG to express a particular preference for any of the 
options suggested earlier in this thread.

The TAG's overriding concern is that a facility for marking web service 
operations as safe in web service descriptions is both available and 
used. We believe that the WGs are in the best position to decide on the 
trade-offs of how the facility is factored between SAWSDL and WSDL 
deliverables.

Best regards

Stuart Williams
co-chair W3C TAG
--
[1] http://www.w3.org/2001/tag/2007/02/26-minutes.html#item06

Jonathan Marsh wrote:
> This is probably a good forum to air my two cents, with my WSDL chair hat
> off.  See below...
>
> Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
>  
>
>   
>> -----Original Message-----
>> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of
>> Jacek Kopecky
>> Sent: Friday, February 09, 2007 5:15 AM
>> To: TAG mailing list
>> Subject: WSDL 2.0 operation safety annotation in SAWSDL?
>>
>>
>> Dear TAG members, others,
>>
>> as the TAG has requested some time ago (see the WSDL issue [1]),
>> WSDL 2.0 now has an annotation on interface operations that indicates
>> whether the operation is known to be safe, in terms of the Web
>> architecture. The syntax looks like this:
>>
>> <wsdl:interface name="printer">
>>   <wsdl:operation name="readCapabilities" wsdlx:safe="true">
>>      ...
>>   </wsdl:operation>
>> </wsdl:interface>
>>
>> Within WSDL itself, this annotation is used by the HTTP binding which
>> will default to using the GET HTTP method for safe operations and POST
>> for those not marked as safe.
>>     
>
> I note that the primary utility of the wsdlx:safe annotation is not to
> default the binding to GET in the absence of other information (there are
> two other ways to explicitly set the operation to GET which take precedence
> over wsdlx:safe).  The primary utility is to mark a POST operation as safe,
> as POST may be a preferable method for reasons other than indicating safety.
> There is no dependency between the HTTP binding and wsdlx:safe in this case.
>
> As is, safety seems to me to be just as abstract a concept as when to use
> GET vs POST is, and I suspect the vast majority of users who want to use GET
> in their HTTP binding won't miss using the indirect syntax of wsdlx:safe,
> but instead will simply set the http method directly.  This doesn't reduce
> the need to understand safety, but simply eliminates duplicate ways to do
> the same thing, a rather tricky dependency, and a layer of abstraction
> tangential to the primary purpose of the extension.
>
> In sum, the dependency between the HTTP binding and the wsdlx:safe extension
> is not one that is essential to the marking of safety.  IMO the HTTP binding
> would be better off without such a dependency.
>
>   
>> Recently it occurred to me, as a participant in both the WS-Description
>> WG and the Semantic Annotations for WSDL WG, that safety falls squarely
>> within the scope of Semantic Annotations [2] (at least IMHO), and that
>> it should be expressed as
>>
>> <wsdl:operation name="readCapabilities"
>>    sawsdl:modelReference="http://www.w3.org/2006/01/wsdl-
>> extensions#SafeInteraction">
>>   ...
>> </wsdl:operation>
>>
>> As you are the main body that requested that WSDL has this annotation,
>> it's only prudent to ask you, what do you think about this alternative
>> way of marking operation safety?
>>
>> There have been reservations to this change in the WS-Desc WG:
>>
>> WSDL is a Candidate Recommendation and safety is not a feature marked as
>> "at risk", so removing it could mean a set-back to WSDL timeline.
>> However, I'm not sure how the W3C would look at moving a feature from
>> one CR spec to another CR spec (SAWSDL is in CR as well), and whether
>> getting back to Working Draft would be necessary.
>>
>> The SAWSDL syntax is much longer, making it harder for designers
>> hand-coding WSDL files to mark operations as safe. Also, the safety
>> annotation URI can get visually lost in other annotations, should the
>> operation be annotated with multiple semantic concepts; a casual reader
>> of the WSDL would not necessarily notice that an operation is marked as
>> safe.
>>
>> WSDL HTTP binding requires that processors understand the wsdlx:safe
>> extension in order to be able to do the defaulting; making SAWSDL
>> required (and a dependency for WSDL) would likely be an overkill. I'm
>> sure that some kind of optionality could be introduced (not changing any
>> current intent anyway) that would make SAWSDL not required.
>>
>> And finally, the WSDL component model has a property {safe} on Interface
>> Operations to represent abstractly the safety annotation, and this could
>> be redundant to the presence of the ...#SafeInteraction URI in the
>> {model reference} property introduced by SAWSDL.
>>
>> There are a number of options that we can see, and we'd like to see
>> whether you have any preference:
>>
>>      1. status quo, no safety in SAWSDL, only in WSDL
>>      2. WSDL defines safety using SAWSDL for syntax (ending up with the
>>         {safe} and {model reference} abstract redundancy)
>>      3. WSDL drops the definition of safety, SAWSDL adds it in the
>>         normative spec, WSDL HTTP binding still uses the annotation for
>>         defaulting
>>     
>
> Because of the reasons I outline above, I think the totally clean separation
> of concerns approach also is workable (indeed, preferable):
>
>       3a. WSDL drops the definition of safety and the dependency upon it 
>           from the HTTP binding, SAWSDL adds it in the normative spec.
>           The WSDL primer continues to recommend when to use GET or POST,
>           reinforce the importance of safety, and provide examples and
>           pointers to the SAWSDL spec.
>
>   
>>      4. WSDL keeps safety as it is (wsdlx:safe="true"), SAWSDL adds a
>>         competing annotation in its non-normative Usage Guide; we'd let
>>         the stronger one survive, but we might get lack of interop
>>         between processors that support one or the other.
>>
>> It might be useful also to mention that it currently seems SAWSDL should
>> go to Rec only shortly after WSDL, if not together.
>>     
>
> Especially in light of this, it should be clear that we're not depriving
> users of anything if WSDL dropped wsdlx:safe, but instead eliminating
> duplicate ways to say the same thing, providing a family of specs with a
> clear and understandable separation of concerns without needlessly knotty
> interdependencies.
>
> With my chair hat back on, I'd like to encourage quick action on this, as
> WSDL is likely to exit CR before the end of the month.  For us at this point
> the easiest procedural path is the status quo - which may turn out to be the
> worst of the options presented above from the user's perspective.
>
>   
>> Best regards,
>>
>> Jacek Kopecky
>> member of WS-Desc WG and chair of SAWSDL WG
>>
>> [1] http://www.w3.org/2002/ws/desc/5/cr-issues/#CR021
>> [2] http://www.w3.org/TR/sawsdl
>>     
>
>
>
>

Received on Tuesday, 27 February 2007 11:13:48 UTC