Round 4- 20040116 - SOAP v1.2(c) Test Collection

Hi,

Following my earlier 3 rounds of submissions on SOAP v1.2(c)
errors, I'm trying to post Round 4 of issue list collected.

The issues found in this round are post-syntax verification
in nature.  I've attempted to remove any duplicated postings
that have been in the earlier rounds.  Some test numbers
that have been posted earlier are again included for a 
different reason or different error source (after the earlier
posted errors have been fixed).

Thanks.



Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/


--------------------------------------------------------------

Test:T27
Note that Node C's fault message says that the array is declared 
as array of integers, but Node A's message is "echoStringArray"
and the enc:itemType attribute is "xs:string".  The entire test
should be changed from "echoStringArray" to "echoIntegerArray",
and enc:itemType changed to "xs:int" instead.

The Description and Node A's message then become:

+.+.+.+.+.+.+.+.+.+.+.+.+.+.
Description:
Node A sends to node C message with test:echoIntegerArray that has 
encodingStyle attribute with a value of 
"http://www.w3.org/2003/05/soap-encoding", contains an element with 
attribute enc:itemType="xsd:int" (array of integer), but with the 
child element of a complex type. Node C returns a Fault indicating 
that message didn't follow SOAP encoding rules (encoded array content 
didn't correspond to the type declared in the enc:itemType).


Node A's Message:

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">
<env:Body>
  <test:echoIntegerArray xmlns:test="http://example.org/ts-tests"
    xmlns:enc="http://www.w3.org/2003/05/soap-encoding"
    env:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
    <test:array enc:itemType="xs:int" enc:arraySize="1">
      <a>
       <b>1</b>
      </a>
    </test:array>
  </test:echoIntegerArray>
</env:Body>
</env:Envelope>
+.+.+.+.+.+.+.+.+.+.+.+.+.+.






Test:T33
Node C's response message does not contain RPC namespace
definition.

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>
  <env:Fault>
    <env:Code>
      <env:Value>env:Sender</env:Value>
      <env:Subcode>
        <env:Value>rpc:ProcedureNotPresent</env:Value>
      </env:Subcode>
    </env:Code>
    <env:Reason>
      <env:Text xml:lang="en-US"> Procedure Not Present </env:Text>
    </env:Reason>
  </env:Fault>
</env:Body>
</env:Envelope>


should be:

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
  xmlns:rpc="http://www.w3.org/2003/05/soap-rpc">
<env:Body>
  <env:Fault>
    <env:Code>
      <env:Value>env:Sender</env:Value>
      <env:Subcode>
        <env:Value>rpc:ProcedureNotPresent</env:Value>
      </env:Subcode>
    </env:Code>
    <env:Reason>
      <env:Text xml:lang="en-US"> Procedure Not Present </env:Text>
    </env:Reason>
  </env:Fault>
</env:Body>
</env:Envelope>





Test:T61
The description:
"Node A sends to Node C a message specifying an array with
bound specified by an asterisk. Node C responds with the
count of items that appeared in the input array."

should be:

"Node A sends to Node C a message specifying an array with
bound specified by a mixed use of integer and an asterisk.
Node C responds with a fault stating such use of asterisk
is invalid."





Test:T63
The description does not indicate what the server should return
if the client sends a proper 2-character content string.
Thus, the description is not complete.
Client must send a non-2-character content string in order to
pass the test.

As the semantics of the test is really to test the length of string,
the test name should be more properly labeled as

<test:validateStringLength>

instead of

<test:validateCountryCode>

Assuming the semantics of the current description, a 2-character
country code of "XX", for example, would pass the test, but yet 
represents an invalid country code in real life.






Test:T66
Description says:
"Node A sends a message to node C with non-empty [encoding]
property. Node C responds by sending the appropriate
'responseOk'."

It should be better refined as "XML encoding" since there
is a chance of confusing with SOAP encoding.  The description
could be corrected with:

"Node A sends a message to node C with non-empty [XML encoding]
property. Node C responds by sending the appropriate
'responseOk'."

Also, Message A's XML encoding value of "UTF8" is incorrect.
It should be "UTF-8" instead.






Test:T76
Second Message A's enc:ref="data" reference needs to have a
"#" prepended in front of "data", as in Test:T57.





Test:TH5 (085)
The notion of "invalid" content-type value interpreted in SOAP 1.2
context is questionable.  SOAP connections and interpretations form
a subset of operations under the HTTP operating domain, triggered
by a content-type being specified as "application/xml+soap".
In a HTTP server capable of handling multiple POSTed content-types,
the interpretation of the POSTed content would have been dependent
on the content-type value specification sent by the connecting client.
If this content-type value has not been "application/xml+soap",
then the POSTed content may not have been interpreted as a SOAP
message in the first place.

In this example case, by definition, the relevant processing logic
would have been to invoke an application that would have been
capable of interpreting data of content-type "audio/mpeg".
Therefore, an error should have been then generated by that
audio/mpeg application instead of generating a HTTP error;
it need not be a HTTP error in the first place if the application
is successfully invoked by the HTTP server.


Thus, the Message C sample:

HTTP/1.1 415 Unsupported Media

should not be generated because the connection has not "bound" to 
SOAPv1.2 specification on HTTP-binding through the content-type 
using "application/xml+soap".  This test case, therefore,
does not test anything specific to SOAPv1.2.

It is therefore recommended that this test be excluded entirely
from this Test Specification.





Test:SBR2-echoBoolean (099)
Message A's xsd type for <inputBoolean> should be "xsd:boolean".




Test:SBR2-echoNestedStructResponse (103)
Message C's <return> tag's and its child, <varStruct>'s,
attributes "xsi:type" should hold the value "ns1:SOAPStruct"
instead of "ns1:SOAPStructStruct".





Test:XMLP-10 (160)
The namespace values of Message A & C's "test" prefix appears
to be confusing when compared to the use of "test" in other tests.
This is also especially so when Message C's content defines
prefix "ns1" as

	xmlns:ns1="http://example.org/ts-tests/xsd"

and the namespace value of "test" is neither
	"http://soapinterop.org/" (prefix "sb" in other tests),
or	"http://example.org/ts-tests"	(prefix "test" in other tests)


Either change all prefix of both Messages A & C's "test" to
"sb", and change "xmlns:test" to "xmlns:sb", or change all
occurrences of namespace values of "http://soapinterop.org/ts-tests"
to "http://example.org/ts-tests".  We favor the latter change.

So after a change to the latter, Messages A & C look like:

+.+.+.+.+.+.+.+.+.+.+.+.+.+.
Node A's Message:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<env:Body>
  <test:echoSimpleTypesAsStructOfSchemaTypes 
    xmlns:test="http://example.org/ts-tests" 
    env:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
    <input1 xsi:type="xsd:int">42</input1> 
    <input2 xsi:type="xsd:float">0.005</input2> 
    <input3 xsi:type="xsd:string">hello world</input3> 
    <input4>Untyped information</input4> 
  </test:echoSimpleTypesAsStructOfSchemaTypes>
</env:Body>
</env:Envelope>


Node C's Message

<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<env:Body>
  <test:echoSimpleTypesAsStructOfSchemaTypesResponse
    xmlns:test="http://example.org/ts-tests"
    xmlns:rpc="http://www.w3.org/2003/05/soap-rpc"
    env:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
    <rpc:result>return</rpc:result>
    <return xsi:type="ns1:SOAPStructTypes"
      xmlns:ns1="http://example.org/ts-tests/xsd">
      <type1 xsi:type="xsd:QName">xsd:int</type1>
      <type2 xsi:type="xsd:QName">xsd:float</type2>
      <type3 xsi:type="xsd:QName">xsd:string</type3>
      <type4 xsi:type="xsd:QName">xsd:anyType</type4>
    </return>
  </test:echoSimpleTypesAsStructOfSchemaTypesResponse>
</env:Body>
</env:Envelope>

+.+.+.+.+.+.+.+.+.+.+.+.+.+.





Test:XMLP-12 (162)
Node C's response message does not contain RPC namespace
definition.

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>
  <env:Fault>
    <env:Code>
      <env:Value>env:Sender</env:Value>
      <env:Subcode>
        <env:Value>rpc:ProcedureNotPresent</env:Value>
      </env:Subcode>
    </env:Code>
    <env:Reason>
      <env:Text xml:lang="en-US"> Procedure Not Present </env:Text>
    </env:Reason>
  </env:Fault>
</env:Body>
</env:Envelope>


should be:
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
  xmlns:rpc="http://www.w3.org/2003/05/soap-rpc">
<env:Body>
  <env:Fault>
    <env:Code>
      <env:Value>env:Sender</env:Value>
      <env:Subcode>
        <env:Value>rpc:ProcedureNotPresent</env:Value>
      </env:Subcode>
    </env:Code>
    <env:Reason>
      <env:Text xml:lang="en-US"> Procedure Not Present </env:Text>
    </env:Reason>
  </env:Fault>
</env:Body>
</env:Envelope>





Test:XMLP-18 (168)
Description says     '... and a role attribute with a value of "true".'
should be changed to '... and a relay attribute with a value of "true".'.

--------------------------------------------------------------





Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/

Received on Monday, 19 January 2004 11:52:26 UTC