As WSDL 2.0 approaches it’s launch into Proposed Recommendation, Jacek has pointed out the apparently duplication between the wsdlx:safe annotation (and it’s corresponding {safety} property) and the Semantic Annotations for WSDL sawsdl:modelReference="http://www.w3.org/2006/01/wsdl-extensions#SafeInteraction" annotation.  Both these annotations have essentially the same characteristics.  How should the existence of two ways to say the same thing be rationalized with the goal of standardization, which is how to agree on one way to say something so we have the best chance of understanding each other?

The issue has now found it’s way to the TAG for their comment.  I already put in my two cents.  But part of my claim may benefit from some exposition.

Besides the spelling of the feature (wsdlx:safe="true" vs. sawsdl:modelReference="…#SafeInteraction") and the terminology underlying it ({safety} vs. {modelReference}), there is only one other significant difference between the two mechanisms.  That is, that the WSDL 2.0 HTTP Binding has a dependency upon the wsdlx:safe annotation.

If the HTTP Binding moved its dependency to SAWSDL, it might accidentally suck in the whole SAWSDL framework, overkill if all you really want to implement is the HTTP Binding, like a tapioca pearl drink when all you have is a regular size straw (wsdlx:safe is small enough to slip through a coffee stirrer).  So unless this dependency can be dislodged, our only reasonable choice is to discourage SAWSDL from competing with our wsdlx:safe extension.  That would be unfortunate because wsdlx:safety sticks out like the energizer bunny in a polar bear habitat.  Safety really describes "what does the service do" rather than "how do I use it" which is what WSDL is really about.  SAWSDL seems a much more appropriate home for the concept of safety.

The detail of the dependency is, that when an operation is marked as safe (wsdlx:safe="true"), and bound with the WSDL 2.0 HTTP binding, and there is no default HTTP method specified (whttp:methodDefault), and there is not explicit method on the operation (whttp:method), the operation will be bound to GET rather than POST.  Notice that:

1. Removing wsdlx:safe does not prevent someone from binding an operation to GET.
2. If you really want GET, whttp:method="GET" is much more straightforward than wsdlx:safe="true" and omitting the whttp:method.

Which came first, GET or safety?  GET is the poster child for why safety is interesting.  Safety is the abstract quality of GET that has proven so useful on the Web.  As an abstraction, it’s by definition less concrete to users.  Most of the people I know that understand safety thoroughly understand GET thoroughly, so it’s unlikely that anyone who asserts safety will be unable to figure out how to simply bind explicitly to GET instead.  And I think there are quite a few people who can use GET without understanding the subtleties of safety.  And indeed, that level of abstraction can be dangerous to those who don’t know what safety is.  "Yes, it’s safe to dereference the URL ‘debit me $100′ because I don’t have a criminal record.  So I’ll mark that operation as safe."  I don’t think you have this understanding problem with GET.

So why is safe interesting at all if it’s simply a synonym for GET?  Well, I think that’s a bit backwards.  GET is often equated with safety, but POST can have the property of "safe interaction" as well.  Perhaps you want to invoke a safe operation with a bulky payload like a SOAP envelope for which POST is appropriate.  The knowledge that the POST was safe could be used by caching infrastructure with immediate benefits.  But the HTTP binding’s dependency has nothing to do with this primary use case.  So sawsdl:modelReference is just as good for that usage as wsdlx:safe.

So why did safety end up in WSDL in the first place?  Well, it seemed like a good train to latch onto at the time, and we fought back many similar requests to hook cars to that train.  Eventually I think it became clear to the "hookers" that this train wasn’t actually leaving the station for a while (this week marks the 5th anniversary of our first teleconference).  They mostly went looking for other trains.  I say let’s unhook this caboose since once it’s attached it can never really be unattached, even if our train is going somewhere different than the caboose wants to.

I suspect the decision will come down to whether SAWSDL is perceived to have enough momentum to become a common companion to WSDL 2.0.  I also suspect SAWSDL would like to keep this functionality because it might drive initial adoption.  I just implemented SAWSDL annotations in wsdl-xslt, showing that the extensions are rather trivial from the WSDL perspective.  Maybe that demonstration will also help drive SAWSDL adoption, and thereby allow us to restore safety to it’s rightful family.