Issue 19Rec

I had taken an action to investigate issue 19Rec [1].

Here are my suggestions to deal with this issue:

--------------------------------------------------------------
>
>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>
>+.+.+.+.+.+.+.+.+.+.+.+.+.+.
>

It is not necessary to change the test. The detail element in the fault
really should say 'array of strings' instead of 'array of integers'.

Suggested action: replace 'array of integers' with 'array of strings' in
the detail element.

>
>
>
>
>
>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>
>

Suggested action: Accept the suggested fix. This requires adding the 
namespace prefix 'rpc' definition to the message from Node C.

>
>
>
>
>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."
>
>

The description indeed isn't correct. But the problem is not the mixed
use of integer and asterisk, but the fact that soap encoding allows
asterisk only in the 1st position of the dimension list.

Suggested action: Replace the description with --
"Node A sends to Node C a message containing an array with a list of
dimensions consisting of an integer followed by an asterisk. Node C
responds with a fault stating that the asterisk can occur only in the
first position in the dimension list."

>
>
>
>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.
>
>

The test describes only the fault scenario. Non-fault cases are not
relevant here. It should more appropriately be named
test:validateStringLength, but this would really be a cosmetic change at
this point.

Suggested action: do nothing.

>
>
>
>
>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'."
>

The test description uses the same terminology as the SOAP 1.2 specs.
The [encoding] property refers to the charset and not soap encoding.

Suggested action: do nothing

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

Suggestion action: accept the suggested fix. Replace 'UTF8' by 'UTF-8'.

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

Actually T76 is fine, it is the other tests that should not have the '#'
as the first character as the value of enc:ref attribute.

Suggested action:

The character '#' should be removed from the following places:
1) Test T56, message sent from Node A, element - inputString
2) Test T57, message sent from Node A, element - test:inputString
3) Test T57, message sent from Node A, element - item

>
>
>
>
>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.
>

It is quite possible to have a SOAP node listen at the specified 
endpoint. Such a SOAP node may require that every message sent be a SOAP 
message and nothing else. I.e., the endpoint is not multiplexed between 
applications. Such a SOAP node may check the content-type as the first 
thing it does before it looks at the HTTP entity-body and sent back a 
415 HTTP status code. This is exactly what the test does. This test is 
for a particular scenario and setup. It does not say anthing about how 
people may actually deploy SOAP in their applications.

Suggested action: do nothing.

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

Suggested action: accept the fix, replace "decimal" with "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".
>

Suggested action: do nothing for the xsi:type attribute of the <return> 
tag -- that is correct. Replace 'ns1:SOAPStructStruct" value of the 
xsi:type attr of the <varStruct> element with "ns1:SOAPStruct".

>
>
>
>
>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>
>
>+.+.+.+.+.+.+.+.+.+.+.+.+.+.
>

The namespace prefix change does not affect the test at all. It would be 
good to be consistent with the use of particular namespace prefixs. At 
this point I do not see any advantage to changing the namespace prefix.

Suggested action: do nothing.

>
>
>
>
>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>
>

Suggested action: accept the suggested fix. This requires adding the 
namespace prefix 'rpc' definition to the message from Node C.


>
>
>
>
>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".'.
>

Suggested action: accept the suggested fix.

>--------------------------------------------------------------
>


-Anish
--

[1] http://www.w3.org/2000/xp/Group/xmlp-rec-issues.html#x19

Received on Friday, 12 March 2004 14:52:20 UTC