- From: <noah_mendelsohn@us.ibm.com>
- Date: Wed, 28 Jul 2004 17:48:15 -0400
- To: "Martin Gudgin" <mgudgin@microsoft.com>
- Cc: paul.downey@bt.com, xml-dist-app@w3.org
Paul Downey writes: > > FWIW i'm trying to put together some test cases for the WSD > test pack and will try to incorporate as many tests as the XMLP WG > elect to provide combined with WSDL 2.0 descriptions. Paul: the XMLP group also informally suggested that I make here a point that we discussed on our telcon today. It's easy to get confused about conformance requirements for something like SOAP, which is ultimately a wire format. Based on the SOAP Recommendation you can distinguish valid from invalid SOAP messages, and you can determine certain things about the correct interpretation (at a given node) of those that are valid. On the other hand, and this often causes confusion, the SOAP Recommendation does not have conformance rules for what you might call a general purpose SOAP implementation. Let's imagine that I am building an embedded system, for use in a traffic light perhaps, and I know that in this particular application no SOAP headers will ever be needed. According to the SOAP Rec. it's just fine for me to build software that is incapable of sending SOAP headers, as long as the messages I do send conform to the Recommendation. Viewed differently, what value is there in me being forced for conformance reasons to build software into my traffic light if that software (I.e. software to send headers) will never be executed? The SOAP Recommendation is carefully worded to allow such flexibility. Of course, nothing prohibits anyone from building an additional specfication to try and standardize the features that might be found in more general purpose implementations, but the SOAP recommendation doesn't do that. I mention all this because any discussion of developing test cases for SOAP needs to be seen in the above context. There are indeed many useful test cases that you can create; indeed we've got some at [1] but we carefully note that: "Even though the purpose of the SOAP 1.2 Test Suite is to facilitate the creation of interoperable implementations, conformance to the SOAP 1.2 Test Suite does not imply conformance to the SOAP 1.2 specifications; there are mandatory requirements of the specifications that are not tested by the suite (as a simple example, SOAP 1.2 requires that every legal value of a role name is accepted, and all illegal ones rejected). An implementation may be said to be SOAP 1.2 conformant if and only if it it satisfies the conformance requirements specified in SOAP 1.2 specifications. The W3C does not at this time provide for any comprehensive means of testing for such conformance. Similarly, an implementation may conform to the SOAP 1.2 specifications even if it does not support all capabilities tested by the SOAP 1.2 Test Suite. SOAP 1.2 specifications admits special purpose implementations, such as those in dedicated controllers, which may send and receive only a very limited suite of messages; the requirement is that whatever is done be done correctly. An implementation may conform to the SOAP 1.2 specifications even if it does not support all capabilities tested by the SOAP 1.2 Test Suite. The test suite defines higher level application semantics to enable testing and facilitate interoperable implementations. It is not necessary for a SOAP processor to support these higher level semantics to be SOAP 1.2 compliant." I'm not sure how this reflects on WSD test cases, but any test cases developed for SOAP should be seen in the above context, I think. Thank you. Noah [1] http://www.w3.org/TR/2003/REC-soap12-testcollection-20030624/ -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 --------------------------------------
Received on Wednesday, 28 July 2004 17:53:06 UTC