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

Re: [soapbuilders] Round 4 - Illegal Fault Soap Messages for Encoded case

Expand Messages
  • Bob Cunnings
    Hi, According to SOAP 1.1 sec. 4.4 [1] ... All immediate child elements of the detail element are called detail entries and each detail entry is encoded as an
    Message 1 of 6 , Jun 28, 2003
    • 0 Attachment
      Hi,

      According to SOAP 1.1 sec. 4.4 [1]

      "... All immediate child elements of the detail element are called detail
      entries and each detail entry is encoded as an independent element within
      the detail element."
      and goes on to describe the structure of detail entries, and refers to an
      example [2] which is helpful.

      The text in the WSDL 1.1 spec is not the clearest, but what it is saying is
      that since style is "document" then no additional wrapper around the fault
      detail entry is required, unlike "rpc" style operations which need a "method
      wrapper" to enclose the serialized parts (parameters).

      RC


      [1] http://www.w3.org/TR/SOAP/#_Toc478383507
      [2] http://www.w3.org/TR/SOAP/#_Ref477795996

      > Hi,
      >
      > I am looking at results for Round 4 Fault Message Processing.
      >
      > Especially results for,
      > Simple RPC-Encoded
      > http://soapinterop.java.sun.com/soapbuilders/r4/simple-rpc-
      > encoded.wsdl
      >
      > Complex RPC-Encoded
      > http://soapinterop.java.sun.com/soapbuilders/r4/complex-rpc-
      > encoded.wsdl
      >
      > Reading from WSDL 1.1 Spec Section 3.6 it says, only style="document"
      > is assumed since faults do not contain parameters. This means no
      > wrapper elements for parts inside detail.
      >
      > But the results posted for WhiteMesa and Sun are creating wrapper
      > elements for parts inside fault detail.
      >
      > We are trying to test our clients against these servers and we are
      > getting Errors due to this problem.
      >
      > For example detail is being sent as,
      > <detail><ns1:part2 xsi:type="xsd:string">White Mesa
      > Test</ns1:part2></detail>
      >
      > Instead of
      > <detail xsi:type="xsd:string">White Mesa Test</detail>
      >
      >
      > Test Results that i am referring to can be found at,
      > http://www.whitemesa.com/interop/results/r4/faults/simple-rpc-
      > enc/results.htm
      >
      > Appreciate any help,
      > thanks,
      > adi
      >
      >
      >
      >
      >
      >
      > -----------------------------------------------------------------
      > 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/
      >
    • Adi Sakala
      Hi, I am not sure i agree with this. May be i need little more information before i agree. I understand what soap spec says regarding detail. But it doesnt say
      Message 2 of 6 , Jun 30, 2003
      • 0 Attachment
        Hi,

        I am not sure i agree with this. May be i need little more
        information before i agree.

        I understand what soap spec says regarding detail. But it doesnt
        say that the <detail> should ONLY have elements, right?

        Since Fault Messages are going to have only one part, i disagree
        with the wrapping of the fault messages. If detail element can
        provide what you are achieving with the wrapped part element, why do
        we need another level of indirection.

        Can somebody tell me how the soap messages (for faults) would be
        created when i add a binding with Literal Use for faults to the Round
        4 WSDL (simple-rpc-encoded.wsdl for SimpleRpcEncPortType)
        http://soapinterop.java.sun.com/soapbuilders/r4/simple-rpc-
        encoded.wsdl

        Here is the question i would ask, Say i have a fault message
        described as below in WSDL,

        <message name="StringFault">
        <part name="part2" type="xsd:string" />
        </message>

        Say i have two bindings,

        1. RPC - Encoded

        <fault name="SimpleFault">
        <soap:fault name="SimpleFault"
        encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
        use="encoded" namespace="http://soapinterop.org/wsdl" />
        </fault>

        Soap Fault Detail that is being produced looks like,
        <detail><ns1:part2 xsi:type="xsd:string">White Mesa
        Test</ns1:part2></detail>


        2. Document - Literal

        <fault name="SimpleFault">
        <soap:fault name="SimpleFault" use="literal"/>
        </fault>

        I would assume soap fault detail for this binding will look like,
        <detail>White Mesa Test</detail>
        (According to WSDL 1.1 Section 3.5)
        If I am wrong, I would really appreciate if somebody could show me
        how the detail will look like for this binding.

        May be answer to this helps me clarify alittle bit on why we adding
        additional elements inside detail when it is not required.

        Appreciate all the Help,
        thanks,
        Adi


        --- In soapbuilders@yahoogroups.com, "Bob Cunnings" <cunnings@l...>
        wrote:
        > Hi,
        >
        > According to SOAP 1.1 sec. 4.4 [1]
        >
        > "... All immediate child elements of the detail element are called
        detail
        > entries and each detail entry is encoded as an independent element
        within
        > the detail element."
        > and goes on to describe the structure of detail entries, and
        refers to an
        > example [2] which is helpful.
        >
        > The text in the WSDL 1.1 spec is not the clearest, but what it is
        saying is
        > that since style is "document" then no additional wrapper around
        the fault
        > detail entry is required, unlike "rpc" style operations which need
        a "method
        > wrapper" to enclose the serialized parts (parameters).
        >
        > RC
        >
        >
        > [1] http://www.w3.org/TR/SOAP/#_Toc478383507
        > [2] http://www.w3.org/TR/SOAP/#_Ref477795996
        >
        > > Hi,
        > >
        > > I am looking at results for Round 4 Fault Message Processing.
        > >
        > > Especially results for,
        > > Simple RPC-Encoded
        > > http://soapinterop.java.sun.com/soapbuilders/r4/simple-rpc-
        > > encoded.wsdl
        > >
        > > Complex RPC-Encoded
        > > http://soapinterop.java.sun.com/soapbuilders/r4/complex-rpc-
        > > encoded.wsdl
        > >
        > > Reading from WSDL 1.1 Spec Section 3.6 it says, only
        style="document"
        > > is assumed since faults do not contain parameters. This means no
        > > wrapper elements for parts inside detail.
        > >
        > > But the results posted for WhiteMesa and Sun are creating wrapper
        > > elements for parts inside fault detail.
        > >
        > > We are trying to test our clients against these servers and we are
        > > getting Errors due to this problem.
        > >
        > > For example detail is being sent as,
        > > <detail><ns1:part2 xsi:type="xsd:string">White Mesa
        > > Test</ns1:part2></detail>
        > >
        > > Instead of
        > > <detail xsi:type="xsd:string">White Mesa Test</detail>
        > >
        > >
        > > Test Results that i am referring to can be found at,
        > > http://www.whitemesa.com/interop/results/r4/faults/simple-rpc-
        > > enc/results.htm
        > >
        > > Appreciate any help,
        > > thanks,
        > > adi
        > >
        > >
        > >
        > >
        > >
        > >
        > > -----------------------------------------------------------------
        > > 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/
        > >
      • Bob Cunnings
        Hi, Well, it will help to look at the example available in the Round 4 doc/literal fault tests [1] where a literal fault detail like:
        Message 3 of 6 , Jun 30, 2003
        • 0 Attachment
          Hi,

          Well, it will help to look at the example available in the Round 4
          doc/literal fault tests [1]
          where a literal fault detail like:

          <fault name="SimpleFault">
          <soap:fault use="literal"/>
          </fault>

          from the "SimpleDocLitBinding" binding maps ultimately to a message like:

          <message name="StringFault">
          <part name="part2" element="ns3:StringPart"/>
          </message>

          Now in this case the part makes reference to an element, since use is
          "literal". This element is defined in the schema as:

          <element name="StringPart" type="xsd:string"/>

          whose targetNamespace is http://soapinterop.org/types/part. The actual
          instance on the wire might look like:

          <detail>
          <test:StringPart xmlns:test="http://soapinterop.org/types/part">Hello
          World</test:StringPart>
          </detail>

          It's not a matter of having a "wrapper"... an element is an element, and by
          definition has its content enclosed in tags.

          Again, the SOAP 1.1 spec requires that detail entries be namespace qualified
          independent elements, and this requirement is met whether the entry is
          defined in WSDL as literal, in which case the element is defined in a schema
          and "literally" transmitted, or it is defined as encoded, in which case the
          SOAP encoding rules cause a value (an instance of the abstract type
          referenced in the message part) to be transmitted as element content [2]. In
          this case what is seen on the wire might look like:

          <detail>
          <test:part1 xmlns:test="http://example.org/whatever">Hello
          World</test:part1>
          </detail>

          where the localname "part1" was the name of the message part, and
          http://example.org/whatever is the namespace referenced in the soap:fault
          binding extension element by the "namespace" element. This in accordance
          with WSDL 1.1 sec. 3.5.

          RC

          [1] http://soapinterop.java.sun.com/soapbuilders/r4/simple-doc-literal.wsdl
          [2] http://www.w3.org/TR/SOAP/#_Toc478383513
          [3] http://www.w3.org/TR/2001/NOTE-wsdl-20010315#_soap:body

          > Hi,
          >
          > I am not sure i agree with this. May be i need little more
          > information before i agree.
          >
          > I understand what soap spec says regarding detail. But it doesnt
          > say that the <detail> should ONLY have elements, right?
          >
          > Since Fault Messages are going to have only one part, i disagree
          > with the wrapping of the fault messages. If detail element can
          > provide what you are achieving with the wrapped part element, why do
          > we need another level of indirection.
          >
          > Can somebody tell me how the soap messages (for faults) would be
          > created when i add a binding with Literal Use for faults to the Round
          > 4 WSDL (simple-rpc-encoded.wsdl for SimpleRpcEncPortType)
          > http://soapinterop.java.sun.com/soapbuilders/r4/simple-rpc-
          > encoded.wsdl
          >
          > Here is the question i would ask, Say i have a fault message
          > described as below in WSDL,
          >
          > <message name="StringFault">
          > <part name="part2" type="xsd:string" />
          > </message>
          >
          > Say i have two bindings,
          >
          > 1. RPC - Encoded
          >
          > <fault name="SimpleFault">
          > <soap:fault name="SimpleFault"
          > encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
          > use="encoded" namespace="http://soapinterop.org/wsdl" />
          > </fault>
          >
          > Soap Fault Detail that is being produced looks like,
          > <detail><ns1:part2 xsi:type="xsd:string">White Mesa
          > Test</ns1:part2></detail>
          >
          >
          > 2. Document - Literal
          >
          > <fault name="SimpleFault">
          > <soap:fault name="SimpleFault" use="literal"/>
          > </fault>
          >
          > I would assume soap fault detail for this binding will look like,
          > <detail>White Mesa Test</detail>
          > (According to WSDL 1.1 Section 3.5)
          > If I am wrong, I would really appreciate if somebody could show me
          > how the detail will look like for this binding.
          >
          > May be answer to this helps me clarify alittle bit on why we adding
          > additional elements inside detail when it is not required.
          >
          > Appreciate all the Help,
          > thanks,
          > Adi
          >
          >
        • Adi Sakala
          Hi, I understand how the soap faults will look on the wire in the case where wsdl message part is referring to an element and the use is literal. I was
          Message 4 of 6 , Jul 1, 2003
          • 0 Attachment
            Hi,
            I understand how the soap faults will look on the wire in the case
            where wsdl message part is referring to an element and the use is
            literal.

            I was specifically interested in the case where the wsdl fault
            message part refers to an abstract type and the use is literal
            for eg:
            <message name="StringFault">
            <part name="part2" type="xsd:string" />
            </message>

            <fault name="SimpleFault">
            <soap:fault name="SimpleFault" use="literal"/>
            </fault>

            The reason why i was asking the wire format for the above case was,
            because according to WSDL spec, when the message part referes to an
            abstract type in schema and the use is literal (with document style)
            then <soap:body/> or <detail/> elements will be representing the
            abstract type defined by the part on the wire.

            If this is true, then the wire format for above case should look like,
            <detail>My Fault Detail</detail>

            I dont see any testcases in interop for this kind of message and
            binding definition combinations.

            If what i said above is agreeable, then if we write a binding for the
            same message with encoded use,
            i.e
            <fault name="SimpleFault">
            <soap:fault name="SimpleFault"
            encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
            use="encoded" namespace="http://soapinterop.org/wsdl" />
            </fault>

            then according to soap encoding rules the part is referring to a
            simple type(xsd:string). In which case,
            we should be able to create a make detail as the element that
            represents the fault part as,
            <detail xsi:type="xsd:string">My Fault Detail String</detail>

            Instead of,
            <detail>
            <test:part2 xmlns:test="http://example.org/whatever">Hello
            World</test:part2>
            <detail>

            Thanks for the detailed responses.

            thanks,
            Adi



            --- In soapbuilders@yahoogroups.com, "Bob Cunnings" <cunnings@l...>
            wrote:
            > Hi,
            >
            > Well, it will help to look at the example available in the Round 4
            > doc/literal fault tests [1]
            > where a literal fault detail like:
            >
            > <fault name="SimpleFault">
            > <soap:fault use="literal"/>
            > </fault>
            >
            > from the "SimpleDocLitBinding" binding maps ultimately to a message
            like:
            >
            > <message name="StringFault">
            > <part name="part2" element="ns3:StringPart"/>
            > </message>
            >
            > Now in this case the part makes reference to an element, since use
            is
            > "literal". This element is defined in the schema as:
            >
            > <element name="StringPart" type="xsd:string"/>
            >
            > whose targetNamespace is http://soapinterop.org/types/part. The
            actual
            > instance on the wire might look like:
            >
            > <detail>
            > <test:StringPart
            xmlns:test="http://soapinterop.org/types/part">Hello
            > World</test:StringPart>
            > </detail>
            >
            > It's not a matter of having a "wrapper"... an element is an
            element, and by
            > definition has its content enclosed in tags.
            >
            > Again, the SOAP 1.1 spec requires that detail entries be namespace
            qualified
            > independent elements, and this requirement is met whether the entry
            is
            > defined in WSDL as literal, in which case the element is defined in
            a schema
            > and "literally" transmitted, or it is defined as encoded, in which
            case the
            > SOAP encoding rules cause a value (an instance of the abstract type
            > referenced in the message part) to be transmitted as element
            content [2]. In
            > this case what is seen on the wire might look like:
            >
            > <detail>
            > <test:part1 xmlns:test="http://example.org/whatever">Hello
            > World</test:part1>
            > </detail>
            >
            > where the localname "part1" was the name of the message part, and
            > http://example.org/whatever is the namespace referenced in the
            soap:fault
            > binding extension element by the "namespace" element. This in
            accordance
            > with WSDL 1.1 sec. 3.5.
            >
            > RC
            >
            > [1] http://soapinterop.java.sun.com/soapbuilders/r4/simple-doc-
            literal.wsdl
            > [2] http://www.w3.org/TR/SOAP/#_Toc478383513
            > [3] http://www.w3.org/TR/2001/NOTE-wsdl-20010315#_soap:body
            >
            > > Hi,
            > >
            > > I am not sure i agree with this. May be i need little more
            > > information before i agree.
            > >
            > > I understand what soap spec says regarding detail. But it doesnt
            > > say that the <detail> should ONLY have elements, right?
            > >
            > > Since Fault Messages are going to have only one part, i disagree
            > > with the wrapping of the fault messages. If detail element can
            > > provide what you are achieving with the wrapped part element, why
            do
            > > we need another level of indirection.
            > >
            > > Can somebody tell me how the soap messages (for faults) would be
            > > created when i add a binding with Literal Use for faults to the
            Round
            > > 4 WSDL (simple-rpc-encoded.wsdl for SimpleRpcEncPortType)
            > > http://soapinterop.java.sun.com/soapbuilders/r4/simple-rpc-
            > > encoded.wsdl
            > >
            > > Here is the question i would ask, Say i have a fault message
            > > described as below in WSDL,
            > >
            > > <message name="StringFault">
            > > <part name="part2" type="xsd:string" />
            > > </message>
            > >
            > > Say i have two bindings,
            > >
            > > 1. RPC - Encoded
            > >
            > > <fault name="SimpleFault">
            > > <soap:fault name="SimpleFault"
            > > encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
            > > use="encoded" namespace="http://soapinterop.org/wsdl" />
            > > </fault>
            > >
            > > Soap Fault Detail that is being produced looks like,
            > > <detail><ns1:part2 xsi:type="xsd:string">White Mesa
            > > Test</ns1:part2></detail>
            > >
            > >
            > > 2. Document - Literal
            > >
            > > <fault name="SimpleFault">
            > > <soap:fault name="SimpleFault" use="literal"/>
            > > </fault>
            > >
            > > I would assume soap fault detail for this binding will look
            like,
            > > <detail>White Mesa Test</detail>
            > > (According to WSDL 1.1 Section 3.5)
            > > If I am wrong, I would really appreciate if somebody could show
            me
            > > how the detail will look like for this binding.
            > >
            > > May be answer to this helps me clarify alittle bit on why we
            adding
            > > additional elements inside detail when it is not required.
            > >
            > > Appreciate all the Help,
            > > thanks,
            > > Adi
            > >
            > >
          • Bob Cunnings
            Hi, Oh, sorry, I missed the point. You are addressing one of the more confusing cases in WSDL 1.1 sec. 3.5 and the subject of some debate in the past, which I
            Message 5 of 6 , Jul 1, 2003
            • 0 Attachment
              Hi,

              Oh, sorry, I missed the point. You are addressing one of the more confusing
              cases in WSDL 1.1 sec. 3.5 and the subject of some debate in the past, which
              I recall only as being inconclusive.

              It reads, referring to the case use="literal" with <part> referencing a
              type:

              "In the second, the type referenced by the part becomes the schema type of
              the enclosing element (Body for document style or part accessor element for
              rpc style)."

              This may make sense if the type referenced is an complex type, but doesn't
              if the type is a simple type, because the SOAP "Body" and "detail" complex
              types can only have element content as immediate children [1], or at least
              that is my understanding of the situation. In SOAP 1.1 sec. 4.3 the same
              language is used as in the case of the detail element, stating that body
              entries are encoded as independent elements.

              So I've always thought that you simply can't do this, even though the WSDL
              mechanisms allow it, since the result conflicts with the SOAP 1.1 rules. The
              WSDL reader here doesn't handle this second case at all, it accepts type
              references in <part> only if use is encoded, avoiding the issue entirely.

              So I'm of no help on this point. Maybe someone else has insights into this
              or can better recall the outcome of discussions in the past.

              RC

              [1] http://schemas.xmlsoap.org/soap/envelope/


              > Hi Bob,
              > I understand how faults will work when the message part is
              > referring to an element and the use is literal.
              >
              > I was more interested to see how soap fault messages will look like
              > when wsdl message part refers to an abstract type and the use is
              > literal.
              >
              > I mean,
              > <message name="StringFault">
              > <part name="part2" type="xsd:string" />
              > </message>
              >
              > Use is Literal.
              >
              > Appreciate your help,
              > thanks,
              > adi
              >
            • Pete Hendry
              Although section 2.3 says * *type*. Refers to an XSD simpleType or complexType using a QName. section 2.3.1 contradicts this with if the message contents are
              Message 6 of 6 , Jul 1, 2003
              • 0 Attachment
                Although section 2.3 says

                * *type*. Refers to an XSD simpleType or complexType using a QName.

                section 2.3.1 contradicts this with

                "if the message contents are sufficiently complex, then an alternative
                syntax may be used to specify the composite structure of the message
                using the type system directly"

                I think this makes the intention clear ("composite structure") but
                contradicts the definition of "type" above. One reason the simpleType
                may be included is for MIME where the part may be base64Binary or
                hexBinary which are simpleTypes.

                Because the spec is so vague (on just about everything!) different
                implementator can read into it differently and so provide different
                functionality. However, if interop is important to you then I would
                avoid using simple types with "type" (with the exception of defining
                MIME message parts).

                Pete



                Bob Cunnings wrote:

                >Hi,
                >
                >Oh, sorry, I missed the point. You are addressing one of the more confusing
                >cases in WSDL 1.1 sec. 3.5 and the subject of some debate in the past, which
                >I recall only as being inconclusive.
                >
                >It reads, referring to the case use="literal" with <part> referencing a
                >type:
                >
                >"In the second, the type referenced by the part becomes the schema type of
                >the enclosing element (Body for document style or part accessor element for
                >rpc style)."
                >
                >This may make sense if the type referenced is an complex type, but doesn't
                >if the type is a simple type, because the SOAP "Body" and "detail" complex
                >types can only have element content as immediate children [1], or at least
                >that is my understanding of the situation. In SOAP 1.1 sec. 4.3 the same
                >language is used as in the case of the detail element, stating that body
                >entries are encoded as independent elements.
                >
                >So I've always thought that you simply can't do this, even though the WSDL
                >mechanisms allow it, since the result conflicts with the SOAP 1.1 rules. The
                >WSDL reader here doesn't handle this second case at all, it accepts type
                >references in <part> only if use is encoded, avoiding the issue entirely.
                >
                >So I'm of no help on this point. Maybe someone else has insights into this
                >or can better recall the outcome of discussions in the past.
                >
                >RC
                >
                >[1] http://schemas.xmlsoap.org/soap/envelope/
                >
                >
                >
                >
                >>Hi Bob,
                >> I understand how faults will work when the message part is
                >>referring to an element and the use is literal.
                >>
                >> I was more interested to see how soap fault messages will look like
                >>when wsdl message part refers to an abstract type and the use is
                >>literal.
                >>
                >> I mean,
                >> <message name="StringFault">
                >> <part name="part2" type="xsd:string" />
                >> </message>
                >>
                >> Use is Literal.
                >>
                >>Appreciate your help,
                >>thanks,
                >>adi
                >>
                >>
                >>
                >
                >
                >
                >
                >
                >-----------------------------------------------------------------
                >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/
                >
                >
                >
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.