RE: WSDL 2.0 operation safety annotation in SAWSDL?

This is probably a good forum to air my two cents, with my WSDL chair hat
off.  See below...

Jonathan Marsh - -

> -----Original Message-----
> From: [] 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="
> 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

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]
> [2]

Received on Saturday, 10 February 2007 00:46:59 UTC