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

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

Expand Messages
  • Paul Kulchenko
    Hi, Robert! ... No. ... No. There should always be even number of digits. Best wishes, Paul. __________________________________________________ Do You Yahoo!?
    Message 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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.