W3C home > Mailing lists > Public > xmlp-comments@w3.org > September 2002

XML Protocols Issue 243

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 11 Sep 2002 17:05:22 -0400
To: reagle@w3.org
Cc: xmlp-comments@w3.org
Message-ID: <OF4103DC5F.AC2ACC11-ON85256C31.0071E007@lotus.com>


This note is a response to a concern raised in your email [1], which the 
protocols WG has logged as its last call issue #243[2].  You wrote 

>> My comment is more  to Part 1, then this primer, but 
>> I also recommend a requirement of one COMPLETE 
>> implementation of all mandatory features: "Given 
>> different implementations, their variance in the 20% 
>> each fails to do well causes 80% of the users' 
>> headaches."

We believe the essence of your concern to be that we have committed to 
looking for implementations of each of the mandatory features of our 
specification, but not to one single implementation that embodies them 
all.  We discussed your concern at some length at our face to face meeting 
in Palo Alto this week, and I think it's fair to say there is considerable 
sympathy for the spirit of the concern that you raise.   So, we gave some 
thought to how this might reasonably be done.

SOAP is a wire format, and the specification is quite intentionally 
written to not have any notion of a COMPLETE implementation.  Just as a 
simple example, the mandatory responsibilities of a sender are different 
from those of a receiver, and there is no requirement that any one piece 
of software provide both capabilities.  Also, the generation of certain 
faults is mandatory in the abstract, but where you deliver them depends on 
the (optional) message exchange pattern in use (for the request/response 
MEP,  faults generated when processing a request are sent back to the 
requester, but faults generated in processing a response are generally 
known only to the node encountering the error...since we have way to get 
back to the responder.)    A further example of an implementation that 
conforms to mandatory requirements but that fails to illustrate certain 
interesting behaviors:  we expect that many embedded controllers will 
decline all header processing by merely claiming not to "understand" any 
(or most) headers.   So, there is no notion of a COMPLETE implementation, 
and only a few truly mandatory requirements;  there are of course 
mandatory requirements in most particular situations.

That said, we do expect that certain sorts of implementations will be 
reasonably common.  For example, we anticipate that many vendors will 
build relatively general purpose SOAP "servers" that serve as receivers 
for requests and as senders for responses.   Taking all these 
considerations into account, the workgroup has decided that our formal 
criteria for exit from last call will not change, but that we will 
undertake a good faith effort to ensure that implementations exist that 
embody the anticipated common combinations of mandatory (and as 
apppropriate optional) features.  We hope that you will find this approach 
to be appropriate. 

Thank you very much.

[1] http://lists.w3.org/Archives/Public/xmlp-comments/2002Jul/0033.html
[2] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x243

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
Received on Wednesday, 11 September 2002 17:06:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:16:59 UTC