W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2004

RE: Thoughts on MTOM testing

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
Message-ID: <OFBA2BF1C0.446014B1-ON85256EDF.00773F07@lotus.com>

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 


[1] http://www.w3.org/TR/2003/REC-soap12-testcollection-20030624/

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Wednesday, 28 July 2004 17:53:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:26 UTC