Loading ...
Sorry, an error occurred while loading the content.

6413Re: [soapbuilders] Re: jSOAP and MSSOAP3.0 client test results

Expand Messages
  • Robert van Engelen
    Dec 7, 2001
    • 0 Attachment

      I like that SOAP4R tries all extremes, but some things have not been settled
      yet in WSDL/SOAP. I think that pta and sparse arrays are clear to some
      extend, but I find the following example a bit unsettling.

      I was wondering about the validity of sending of nil elements as request
      parameters and the appropriate response to this.

      For example, the WSDL specifies the request message to contain the three

      <message name="echoSimpleTypesAsStructRequest">
      <part name="inputString" type="xsd:string"/>
      <part name="inputInteger" type="xsd:int"/>
      <part name="inputFloat" type="xsd:float"/>

      Now, the SOAP4R client sends me:

      <inputString xsi:nil="true"></inputString>
      <inputInteger xsi:nil="true"></inputInteger>
      <inputFloat xsi:nil="true"></inputFloat>

      The current WSDL spec does not allow the inclusion of xsi:nillable attributes in
      message-part specifications, unlike the data type XML schemas.
      By default I assume that the parameters are non-nillable. Would that be a
      sensible choice? Right now gSOAP faults because it assumes the parameters are

      If they are nillable, then the response might be

      <varString xsi:nil="true"/>
      <varInteger xsi:nil="true"/>
      <varFloat xsi:nil="true"/>

      or it might even be

      <s:SOAPStruct xsi:nil="true"/>

      because the application-level has to decide how the response should be.
      That is my problem with this example: it is not SOAP-specific. The application
      layer has to decide on an appropriate response.

      Forgive my ignorance, but is there any concensus on the "nillability" of
      request parameters?

      - Robert
    • Show all 13 messages in this topic