RE: WSDL 2.0 LC Comments, specifically LC issue 76d

Thanks for the response.  Microsoft is not compelled by this use case as
we understand it.  The wsoap:mustUnderstand attribute appears to be
designed to allow interaction (namely, predictable failure) with a
service that does not support all the features described in the WSDL,
implying that a single WSDL simultaneously describes two incompatible
(in some way) types of service.  The problem of choosing an appropriate
service is a general discovery problem and has to date been treated as
out-of-scope by the Working Group per the charter.

 

Thus, we continue to disagree with the inclusion of wsoap:mustUnderstand
in the specification.

 

________________________________

From: David Orchard [mailto:dorchard@bea.com] 
Sent: Thursday, September 15, 2005 5:53 PM
To: Jonathan Marsh
Cc: public-ws-desc-comments@w3.org
Subject: WSDL 2.0 LC Comments, specifically LC issue 76d

 

Jonathan, 

 

In [1], you expressed concern with the wsoap:mustUnderstand attribute by
saying

"However, we
don't see the utility of the mustUnderstand attribute.  Why would you
put the header in the WSDL if the service didn't understand it?  Please
explain or remove this attribute."

 

The working group decided to keep the wsoap:mustUnderstand attribute but
not create a primer example.

 

A primary motivation for soap:mustUnderstand is to enable a client to
ensure that a service understands a soap header block that the client
sends.  Imagine that an interface is controlled by a 3rd party such as a
travel consortium.  The travel consortia decides to make an element a
soap header block rather than part of the body, perhaps on the initial
version or a subsequent version.  There are a variety of reasons for
this, such as they do not control the schema for the body or even the
interface itself.   The WSDL 2.0 author thus wants to fully specify the
contract between the client and server, which includes mandating
soap:mustUnderstand.   A 3rd party specifying the header block, such as
most Web services specficaitons, is another example of an interface
description language that specifies that the mustUnderstand flag is set
to true.  Whereas a WS-* specification can specify via a Policy
statement attached in WSDL how soap headers are used and any mU
attributes, WSDL 2.0 provides the wsoap:header functionality for WSDL
2.0 authors and for completeness reasons this includes
wsoap:mustUnderstand.  

 

We hope that you find this rationale sufficient.  Please let as know as
soon as possible if you continue to disagree.  

 

Cheers,

Dave Orchard for the WSDL 2.0 WG.

 

[1]
http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005May/0091
.html