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

jSOAP and MSSOAP3.0 client test results

Expand Messages
  • Robert van Engelen
    Hi, I have updated the base and group B gSOAP client test results and included jSOAP and MSSOAP3.0 in the client tests. See:
    Message 1 of 13 , Dec 6, 2001
    • 0 Attachment
      Hi,

      I have updated the base and group B gSOAP client test results and included
      jSOAP and MSSOAP3.0 in the client tests. See:

      http://www.cs.fsu.edu/~engelen/interop2results.html
      http://www.cs.fsu.edu/~engelen/interop2Bresults.html

      Congratulations to Spheon jSOAP! MS SOAP3.0 looks good but has some problems.

      I encountered one problem with gSOAP <-> jSOAP that might be a problem of
      gSOAP: the hexBinary string has an uneven number of digits when echoed by
      jSOAP. Is this valid? For example, is the folling hexBinary encoding valid?

      <item>FF0</item>

      I suppose this resembles FF00?

      Also: Apache 2.2/Axis, GLUE, and kSOAP endpoints seem to be down.

      - Robert
    • Paul Kulchenko
      Hi, Robert! ... No. ... No. There should always be even number of digits. Best wishes, Paul. __________________________________________________ Do You Yahoo!?
      Message 2 of 13 , Dec 6, 2001
      • 0 Attachment
        Hi, Robert!

        --- Robert van Engelen <engelen@...> wrote:
        > jSOAP. Is this valid? For example, is the folling hexBinary
        > encoding valid?
        No.

        > <item>FF0</item>
        > I suppose this resembles FF00?
        No. There should always be even number of digits.

        Best wishes, Paul.

        __________________________________________________
        Do You Yahoo!?
        Send your FREE holiday greetings online!
        http://greetings.yahoo.com
      • Rich Salz
        No, an odd number of digits is illegal. -- Zolera Systems, Your Key to Online Integrity Securing Web services: XML, SOAP, Dig-sig, Encryption
        Message 3 of 13 , Dec 6, 2001
        • 0 Attachment
          No, an odd number of digits is illegal.

          --
          Zolera Systems, Your Key to Online Integrity
          Securing Web services: XML, SOAP, Dig-sig, Encryption
          http://www.zolera.com
        • Alan Kent
          ... Do you have wire dumps available? I suspect some of the faults reported with my end point (SIM) *might* be related to p-t-a/sparse etc encoding which I
          Message 4 of 13 , Dec 7, 2001
          • 0 Attachment
            On Thu, Dec 06, 2001 at 11:33:23AM -0500, Robert van Engelen wrote:
            > Hi,
            >
            > I have updated the base and group B gSOAP client test results and included
            > jSOAP and MSSOAP3.0 in the client tests. See:
            >
            > http://www.cs.fsu.edu/~engelen/interop2results.html
            > http://www.cs.fsu.edu/~engelen/interop2Bresults.html

            Do you have wire dumps available? I suspect some of the faults reported
            with my end point (SIM) *might* be related to p-t-a/sparse etc encoding
            which I dont think has reached a final conclusion yet. But I cannot
            be sure without a wire dump.

            Also, I remember seeing Map and Map Array in people's conversations,
            but is there some more official statement as to if its in the interop
            tests at present? I don't mind having a go, but don't know what the
            definition is that I should be doing.

            Thanks,
            Alan
          • NAKAMURA, Hiroshi
            Hi, ... Though I agree that p-t-a/sparse encoding has not reached a final conclusion yet, IONA XMLBus, Spray2001 and SOAP4R seems to have the similar
            Message 5 of 13 , Dec 7, 2001
            • 0 Attachment
              Hi,

              > From: Alan Kent [mailto:ajk@...]
              > Sent: Friday, December 07, 2001 5:01 PM

              > Do you have wire dumps available? I suspect some of the faults reported
              > with my end point (SIM) *might* be related to p-t-a/sparse etc encoding
              > which I dont think has reached a final conclusion yet. But I cannot
              > be sure without a wire dump.

              Though I agree that p-t-a/sparse encoding has not reached
              a final conclusion yet, IONA XMLBus, Spray2001 and SOAP4R
              seems to have the similar understanding about it.

              Daniel, Steve: Correct me if I'm going to far with this.

              > Also, I remember seeing Map and Map Array in people's conversations,
              > but is there some more official statement as to if its in the interop
              > tests at present? I don't mind having a go, but don't know what the
              > definition is that I should be doing.

              The SOAP4R interpo endpoint implements echoMap and
              echoMapArray but SOAP4R has not support WSDL related
              function yet... Is there anybody wrote it?

              Regards,
              // NaHi
            • NAKAMURA, Hiroshi
              Hi, ... I ve released SOAP4R/1.4.1 and is re-running all test to check. I found 4s4c server seems to support multi-ref encoding/decoding and p-t-a/sparse
              Message 6 of 13 , Dec 7, 2001
              • 0 Attachment
                Hi,

                > From: NAKAMURA, Hiroshi [mailto:nahi@...]
                > Sent: Friday, December 07, 2001 6:55 PM

                > Though I agree that p-t-a/sparse encoding has not reached
                > a final conclusion yet, IONA XMLBus, Spray2001 and SOAP4R
                > seems to have the similar understanding about it.

                I've released SOAP4R/1.4.1 and is re-running all test to check.
                I found 4s4c server seems to support multi-ref
                encoding/decoding and p-t-a/sparse array. Great!

                Regards,
                // NaHi
              • Robert van Engelen
                Hi, 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,
                Message 7 of 13 , Dec 7, 2001
                • 0 Attachment
                  Hi,

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

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

                  Now, the SOAP4R client sends me:

                  <n2:echoSimpleTypesAsStruct
                  env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
                  xmlns:n1="http://schemas.xmlsoap.org/soap/encoding/"
                  xmlns:n2="http://soapinterop.org/">
                  <inputString xsi:nil="true"></inputString>
                  <inputInteger xsi:nil="true"></inputInteger>
                  <inputFloat xsi:nil="true"></inputFloat>
                  </n2:echoSimpleTypesAsStruct>

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

                  If they are nillable, then the response might be

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

                  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
                • Robert van Engelen
                  ... Click on the name of the toolkit (SIM) for the wire dumps which is best viewed with Netscape because IE thinks that it has to apply cascading style sheets
                  Message 8 of 13 , Dec 7, 2001
                  • 0 Attachment
                    Alan Kent wrote:

                    > Do you have wire dumps available? I suspect some of the faults reported
                    > with my end point (SIM) *might* be related to p-t-a/sparse etc encoding
                    > which I dont think has reached a final conclusion yet. But I cannot
                    > be sure without a wire dump.

                    Click on the name of the toolkit (SIM) for the wire dumps which is best viewed
                    with Netscape because IE thinks that it has to apply cascading style sheets
                    for whatever reason, resulting in an error. The first part are the messages
                    sent, the second the messages received. I do test pta and sparse: the string
                    array is sparse and the struct array is pta.

                    - Robert
                  • Bob Cunnings
                    Hi, If SOAP encoding is in force, then the serialization rules it prescribes govern how the RPC request/response may be represented on the wire. The subject
                    Message 9 of 13 , Dec 7, 2001
                    • 0 Attachment
                      Hi,

                      If SOAP encoding is in force, then the serialization rules it prescribes govern how the RPC request/response may be represented on the wire. The subject comes up from time to time, take a look at

                      http://groups.yahoo.com/group/soapbuilders/message/5513

                      The distinction between abstract type definition (using XML Schema) and the encoding (wire representation) of that type in a SOAP Section 5 message has to be maintained. In fact, WSDL 1.1 takes pains to place restrictions on the content of Schemas used to describe message parts, stating regarding "... recommended approach for encoding abstract types using XSD..." the advice "Don't include attributes or elements that are peculiar to the wire encoding (e.g. have nothing to do with the abstract content of the message). Some examples are soap:root, soap:encodingStyle, xmi:id, xmi:name." [1]

                      "nil" is a perfectly fine to use in the Schema as part of an element definition, but the "null" (or "nill") used in SOAP encoding to adorn an accessor element is a different thing entirely, it appears, with no relation to anything in the schema (if one exists).

                      RC

                      [1] http://www.w3.org/TR/wsdl#_types

                      >
                      > Hi,
                      >
                      > 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
                      > parameters:
                      >
                      > <message name="echoSimpleTypesAsStructRequest">
                      > <part name="inputString" type="xsd:string"/>
                      > <part name="inputInteger" type="xsd:int"/>
                      > <part name="inputFloat" type="xsd:float"/>
                      > </message>
                      >
                      > Now, the SOAP4R client sends me:
                      >
                      > <n2:echoSimpleTypesAsStruct
                      > env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
                      > xmlns:n1="http://schemas.xmlsoap.org/soap/encoding/"
                      > xmlns:n2="http://soapinterop.org/">
                      > <inputString xsi:nil="true"></inputString>
                      > <inputInteger xsi:nil="true"></inputInteger>
                      > <inputFloat xsi:nil="true"></inputFloat>
                      > </n2:echoSimpleTypesAsStruct>
                      >
                      > 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
                      > non-nillable.
                      >
                      > If they are nillable, then the response might be
                      >
                      > <s:SOAPStruct>
                      > <varString xsi:nil="true"/>
                      > <varInteger xsi:nil="true"/>
                      > <varFloat xsi:nil="true"/>
                      > <s:SOAPStruct>
                      >
                      > 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
                      >
                      >
                      >
                      > -----------------------------------------------------------------
                      > This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues. Please stay on-topic.
                      >
                      > To unsubscribe from this group, send an email to:
                      > soapbuilders-unsubscribe@yahoogroups.com
                      >
                      >
                      >
                      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                      >
                      >
                    • nahi_home
                      Hi Robert, Thank you for your comment. I always am glad to hear other s comment! ... Hmm. I understand a schema in WSDL as another thing. Schema defines rules
                      Message 10 of 13 , Dec 7, 2001
                      • 0 Attachment
                        Hi Robert,

                        Thank you for your comment.
                        I always am glad to hear other's comment!

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

                        Hmm. I understand a schema in WSDL as another thing.
                        Schema defines rules which are only refered in
                        encoding/decoding to know type information in nodes
                        in Object graph. Not applicable directly.

                        +------+
                        |Type |
                        |InfoBy|
                        |Schema|
                        +------+ +------+
                        |Typed | | +--------+
                        |Object| V |XML |
                        |graph |<-------->|Instance|
                        +------+ encoding +--------+
                        decoding

                        Of cource, literal encoding(document) is another thing.
                        Using literal encoding, schema must be applied directly.

                        > The current WSDL spec does not allow the inclusion of
                        > xsi:nillable attributes in
                        > message-part specifications, unlike the data type XML schemas.

                        Sure. And I understand nillable is not needed to define
                        explicitly like href, id, position, offset and so on.

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

                        I think there is no concensus about nillability of
                        elements. For testing of interoperability point of view,
                        the echo* application should define how to deal with nil
                        even if SOAP does not define it, IMO. Then, I can
                        swith some test from "regular test" to "negative test".

                        Regards,
                        // NaHi
                      • Matt Long
                        It seems to that if the xsd instrinsic type is used on the message part the all soap encoding rules apply to the the context, including nillable= true , see
                        Message 11 of 13 , Dec 7, 2001
                        • 0 Attachment
                          It seems to that if the xsd instrinsic type is used on the message part the
                          all soap encoding rules apply to the the context, including nillable='true',
                          see WSDL Section 2.2. However, I suppose you could restrict the simpleType
                          by referencing a simpleType in the wsdl schema with a restriction that
                          nillable='false', thus clearly describing the context of the part.

                          Does this make sense?

                          Thx,

                          -Matt

                          <definitions xmlns="wsdl-namespace"
                          targetNamespace="http://soapinterop.org/"
                          xmlns:s="http://soapinterog.org/xsd" />
                          <types>
                          <schema targetNamespace="http://soapinterop.org/xsd"
                          xmlns="http://www.w3.org/2001/XMLSchema">
                          <simpleType name="nonNillableString">
                          <restriction base="string">
                          <nonNillableString nillable="false"/>
                          </restriction>
                          </simpleType>
                          </schema>
                          </types>
                          ...
                          <message name="echoStringRequest">
                          <part name="inputString" type="s:nonNillableString"/>
                          </message>
                          <message name="echoStringResponse">
                          <part name="inputString type="s:nonNillableString">
                          </message>
                          ...
                          </definitions>

                          > -----Original Message-----
                          > From: Robert van Engelen [mailto:engelen@...]
                          > Sent: Friday, December 07, 2001 8:22 AM
                          > To: soapbuilders@yahoogroups.com
                          > Subject: Re: [soapbuilders] Re: jSOAP and MSSOAP3.0 client test results
                          >
                          >
                          >
                          > Hi,
                          >
                          > 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
                          > parameters:
                          >
                          > <message name="echoSimpleTypesAsStructRequest">
                          > <part name="inputString" type="xsd:string"/>
                          > <part name="inputInteger" type="xsd:int"/>
                          > <part name="inputFloat" type="xsd:float"/>
                          > </message>
                          >
                          > Now, the SOAP4R client sends me:
                          >
                          > <n2:echoSimpleTypesAsStruct
                          > env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
                          > xmlns:n1="http://schemas.xmlsoap.org/soap/encoding/"
                          > xmlns:n2="http://soapinterop.org/">
                          > <inputString xsi:nil="true"></inputString>
                          > <inputInteger xsi:nil="true"></inputInteger>
                          > <inputFloat xsi:nil="true"></inputFloat>
                          > </n2:echoSimpleTypesAsStruct>
                          >
                          > 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
                          > non-nillable.
                          >
                          > If they are nillable, then the response might be
                          >
                          > <s:SOAPStruct>
                          > <varString xsi:nil="true"/>
                          > <varInteger xsi:nil="true"/>
                          > <varFloat xsi:nil="true"/>
                          > <s:SOAPStruct>
                          >
                          > 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
                          >
                          >
                          >
                          > -----------------------------------------------------------------
                          > This group is a forum for builders of SOAP implementations to
                          > discuss implementation and interoperability issues. Please stay on-topic.
                          >
                          > To unsubscribe from this group, send an email to:
                          > soapbuilders-unsubscribe@yahoogroups.com
                          >
                          >
                          >
                          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                          >
                        • Robert van Engelen
                          Hi, Thank you all for your comments. As Matt pointed out, the SOAP encoding rules apply to the parameters as well and do not restrict the use of nillable
                          Message 12 of 13 , Dec 7, 2001
                          • 0 Attachment
                            Hi,

                            Thank you all for your comments. As Matt pointed out, the SOAP encoding rules
                            apply to the parameters as well and do not restrict the use of nillable
                            elements in any way.

                            > I think there is no concensus about nillability of
                            > elements. For testing of interoperability point of view,
                            > the echo* application should define how to deal with nil
                            > even if SOAP does not define it, IMO. Then, I can
                            > swith some test from "regular test" to "negative test".

                            I changed my endpoint to accept nillable parameters and there is not need
                            for your client test to change anything.

                            Thanks!

                            - Robert
                          • Alan Kent
                            ... This makes sense to me (with my limited schema/WSDL knowledge). Do most people support this? Could it become the recommended WSDL solution to nil/non-nil
                            Message 13 of 13 , Dec 9, 2001
                            • 0 Attachment
                              On Fri, Dec 07, 2001 at 10:04:07AM -0600, Matt Long wrote:
                              > ... However, I suppose you could restrict the simpleType
                              > by referencing a simpleType in the wsdl schema with a restriction that
                              > nillable='false', thus clearly describing the context of the part.
                              >
                              > Does this make sense?
                              >
                              > Thx,
                              >
                              > -Matt
                              >
                              > <definitions xmlns="wsdl-namespace"
                              > targetNamespace="http://soapinterop.org/"
                              > xmlns:s="http://soapinterog.org/xsd" />
                              > <types>
                              > <schema targetNamespace="http://soapinterop.org/xsd"
                              > xmlns="http://www.w3.org/2001/XMLSchema">
                              > <simpleType name="nonNillableString">
                              > <restriction base="string">
                              > <nonNillableString nillable="false"/>
                              > </restriction>
                              > </simpleType>
                              > </schema>
                              > </types>
                              > ...
                              > <message name="echoStringRequest">
                              > <part name="inputString" type="s:nonNillableString"/>
                              > </message>
                              > <message name="echoStringResponse">
                              > <part name="inputString type="s:nonNillableString">
                              > </message>
                              > ...
                              > </definitions>

                              This makes sense to me (with my limited schema/WSDL knowledge).
                              Do most people support this? Could it become the 'recommended
                              WSDL solution to nil/non-nil parameters'? (Should I be asking
                              this on a WSDL list instead :-)

                              I know SOAP allows nil's to be encoded - but that is not the
                              question. Does the above WSDL successfully say 'inputString
                              cannot be nil' and without the above does it mean 'inputString
                              can be nil'? This impacts the current interop tests as to
                              if sending a nil is OK or not with the WSDL file currently
                              in use.

                              This is one of the final areas where I don't really have a
                              satisfactory answer to - other areas (such as p-t-a and sparse)
                              I believe I fully understand the current position of SOAP
                              (I might not like it, but I understand it :-). Nil's for parameters
                              was the final area of 'lack of functionality' to me.

                              Then, if the above is the correct way to go, should the current
                              interop tests allow or exclude nil? Or both? Or just leave it
                              as it is (which is fine by me).

                              Alan
                            Your message has been successfully submitted and would be delivered to recipients shortly.