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

an oversimplification in mime-doc.wsdl?

Expand Messages
  • travis_atkins <travis_atkins@yahoo.com>
    I m wondering is there is a slight oversimplification in the Round 4 MIME Attachments with Document style SOAP wsdl interop example (
    Message 1 of 5 , Feb 5, 2003
    • 0 Attachment
      I'm wondering is there is a slight oversimplification in the Round
      4 MIME Attachments with Document style SOAP wsdl interop
      example ( http://www.pocketsoap.com/interop/mime-doc.wsdl ).
      The binding sections has two mime parts defined for the input to
      the "EchoAttachment" operation:

      <wsdl:input name="EchoAttachmentInput">
      <mime:multipartRelated>
      <mime:part>
      <soap:body use="literal"/>
      </mime:part>
      <mime:part>
      <mime:content part="In" type="application/octetstream"/>
      </mime:part>
      </mime:multipartRelated>
      </wsdl:input>


      but the corresponding message only has one wsdl "part":

      <wsdl:message name="EchoAttachmentIn">
      <wsdl:part name="In" element="types:EchoAttachment"/>
      </wsdl:message>

      in the type section this eventually boils down to a single href
      which is supposed to point to the mime part:

      <complexType name="binary">
      <simpleContent>
      <extension base="xsd:base64Binary">
      <attribute name="href" type="xsd:anyURI"/>
      </extension>
      </simpleContent>
      </complexType >

      <element name="EchoAttachment" type=
      "types:EchoAttachment"/>

      <complexType name="EchoAttachment">
      <sequence>
      <element name="In" type="types:binary"/>
      </sequence>
      </complexType>


      but what if we have users interested in more than just the data
      pointed to by the element containing the href? By that I mean:
      won't there be cases where the EchoAttachment type contains
      other elements besides just the "In" element? If the stub/skel
      gen tools (like WSDL2Java) are going to give users access to
      the those other elements won't there need to be named part for it
      in either the message or soap:body-mime:part input binding?

      I'm asking because this exact case exists in the 3GPP's
      Multimedia Messaging Service SOAP interface spec for MMS
      relays (commonly known in handset circles as the MM7
      protocol).

      travis
    • Wes Moulder
      Travis, My understanding of the testing is that the initial swa and dime interop tests were just to show that you could actually pass attachments. Rather than
      Message 2 of 5 , Feb 5, 2003
      • 0 Attachment
        Travis,
        My understanding of the testing is that the initial swa and dime interop
        tests were just to show that you could actually pass attachments.
        Rather than a proof of actual use cases, think of the tests as proof
        that systems are able to generate messages that others understand. In
        other words, none of our interop tests have methods that take 10
        arguments, but theoretically, it's interoperable, because we all handle
        the test where we send across 3 and return an agregate.

        In no way is the testing complete, nor can it be, as someone is always
        able to come up with another combination that we haven't tried here.
        That doesn't mean these tests aren't valuable in their own right.

        As for MM7, they have to generate the WSDL that puts the parts in the
        appropriate place, then, WSDL2Java(axis), wsdl2java(glue), and wsdl.exe
        will all be able to understand the actual message signature, and present
        the arguments to the client as appropriate.

        --Wes

        -----Original Message-----
        From: travis_atkins <travis_atkins@...>
        [mailto:travis_atkins@...]
        Sent: Wednesday, February 05, 2003 2:19 AM
        To: soapbuilders@yahoogroups.com
        Subject: [soapbuilders] an oversimplification in mime-doc.wsdl?


        I'm wondering is there is a slight oversimplification in the Round
        4 MIME Attachments with Document style SOAP wsdl interop
        example ( http://www.pocketsoap.com/interop/mime-doc.wsdl ).
        The binding sections has two mime parts defined for the input to
        the "EchoAttachment" operation:

        <wsdl:input name="EchoAttachmentInput">
        <mime:multipartRelated>
        <mime:part>
        <soap:body use="literal"/>
        </mime:part>
        <mime:part>
        <mime:content part="In" type="application/octetstream"/>
        </mime:part>
        </mime:multipartRelated>
        </wsdl:input>


        but the corresponding message only has one wsdl "part":

        <wsdl:message name="EchoAttachmentIn">
        <wsdl:part name="In" element="types:EchoAttachment"/> </wsdl:message>

        in the type section this eventually boils down to a single href
        which is supposed to point to the mime part:

        <complexType name="binary">
        <simpleContent>
        <extension base="xsd:base64Binary">
        <attribute name="href" type="xsd:anyURI"/>
        </extension>
        </simpleContent>
        </complexType >

        <element name="EchoAttachment" type=
        "types:EchoAttachment"/>

        <complexType name="EchoAttachment">
        <sequence>
        <element name="In" type="types:binary"/>
        </sequence>
        </complexType>


        but what if we have users interested in more than just the data
        pointed to by the element containing the href? By that I mean:
        won't there be cases where the EchoAttachment type contains
        other elements besides just the "In" element? If the stub/skel
        gen tools (like WSDL2Java) are going to give users access to
        the those other elements won't there need to be named part for it
        in either the message or soap:body-mime:part input binding?

        I'm asking because this exact case exists in the 3GPP's
        Multimedia Messaging Service SOAP interface spec for MMS
        relays (commonly known in handset circles as the MM7
        protocol).

        travis



        -----------------------------------------------------------------
        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/
      • travis_atkins <travis_atkins@yahoo.com>
        The actual use case of MM7 is a red herring. I only mentioned MM7 because it just happened to be my initial reason for investigating the interoperability of
        Message 3 of 5 , Feb 5, 2003
        • 0 Attachment
          The actual use case of MM7 is a red herring. I only mentioned
          MM7 because it just happened to be my initial reason for
          investigating the interoperability of several SOAP toolkits.

          My point is that I am not sure if the test case actually tests the
          case where there is a binary part and an xml part (which has
          additional elements of interest besides just the one that points
          at the binary part). This scenario -data passed as binary, many
          metadata fields (including a pointer to the binary data) passed
          as xml - is sure to be incredibly common.

          I tried to write the wsdl to test this case this morning, and I would
          appreciate some feedback. I am confused a bit about the
          mapping of the mime parts to the wsdl message "parts". Is there
          any? For instance, if I modified the binding section for the input
          to the "EchoAttachement" in the test wsdl ( http://
          www.pocketsoap.com/interop/mime-doc.wsdl ) by adding a part
          name ("newBodyName") to soap body part:

          <wsdl:input name="EchoAttachmentInput">
          <mime:multipartRelated>
          <mime:part>
          <soap:body part="newBodyName" use="literal"/>
          </mime:part>
          <mime:part>
          <mime:content part="In" type="application/octetstream"/>
          </mime:part>
          </mime:multipartRelated>
          </wsdl:input>

          do I _need_ to add a corresponding "newBodyName" message
          part like this?:

          <wsdl:message name="EchoAttachmentIn">
          <wsdl:part name="newBodyName" element=
          "types:toBeDetermined"/>
          <wsdl:part name="In" element="types:EchoAttachment"/>
          </wsdl:message>

          or can I just leave the single "In" message part like before and
          simply add more elements to the EchoAttachment type like this?:

          <complexType name="EchoAttachment">
          <sequence>
          <element name="foo" type="xsd:string"/>
          <element name="bar" type="xsd:string"/>
          <element name="baz" type="xsd:string"/>
          <element name="timeStamp" type="xsd:dateTime"/>
          <element name="In" type="types:binary"/>
          </sequence>
          </complexType>

          I'm not quite sure which one is right.
          Help completing this test case would be appreciated.

          travis


          --- In soapbuilders@yahoogroups.com, "Wes Moulder" <
          wes@t...> wrote:
          > Rather than a proof of actual use cases, think of the tests as
          proof
          > that systems are able to generate messages that others
          understand.

          > As for MM7, they have to generate the WSDL that puts the parts
          in the
          > appropriate place,
        • Wes Moulder
          At this point, that s more of a spec question than an interop question. From the wsdl spec, I d go with the wsdl segments from below: The gist of it is that
          Message 4 of 5 , Feb 5, 2003
          • 0 Attachment
            At this point, that's more of a spec question than an interop question.
            From the wsdl spec, I'd go with the wsdl segments from below:

            The gist of it is that the return is going to be specified in body, with
            two attachments (unreferenced in the body) that will be an html page and
            a logo that could be a gif or a jpeg or one of each.

            Hope that helps,
            --Wes

            <message name="m2">
            <part name="body" element="tns:GetCompanyInfoResult"/>
            <part name="docs" type="xsd:string"/>
            <part name="logo" type="tns:ArrayOfBinary"/>
            </message>

            <portType name="pt1">
            <operation name="GetCompanyInfo">
            <input message="m1"/>
            <output message="m2"/>
            </operation>
            </portType>

            <binding name="b1" type="tns:pt1">
            <operation name="GetCompanyInfo">
            <soap:operation
            soapAction="http://example.com/GetCompanyInfo"/>
            <input>
            <soap:body use="literal"/>
            </input>
            <output>
            <mime:multipartRelated>
            <mime:part>
            <soap:body parts="body" use="literal"/>
            </mime:part>
            <mime:part>
            <mime:content part="docs" type="text/html"/>
            </mime:part>
            <mime:part>
            <mime:content part="logo" type="image/gif"/>
            <mime:content part="logo" type="image/jpeg"/>
            </mime:part>
            </mime:multipartRelated>
            </output>
            </operation>
            </binding>


            -----Original Message-----
            From: travis_atkins <travis_atkins@...>
            [mailto:travis_atkins@...]
            Sent: Wednesday, February 05, 2003 4:34 PM
            To: soapbuilders@yahoogroups.com
            Subject: [soapbuilders] Re: an oversimplification in mime-doc.wsdl?


            The actual use case of MM7 is a red herring. I only mentioned
            MM7 because it just happened to be my initial reason for
            investigating the interoperability of several SOAP toolkits.

            My point is that I am not sure if the test case actually tests the
            case where there is a binary part and an xml part (which has
            additional elements of interest besides just the one that points
            at the binary part). This scenario -data passed as binary, many
            metadata fields (including a pointer to the binary data) passed
            as xml - is sure to be incredibly common.

            I tried to write the wsdl to test this case this morning, and I would
            appreciate some feedback. I am confused a bit about the
            mapping of the mime parts to the wsdl message "parts". Is there
            any? For instance, if I modified the binding section for the input
            to the "EchoAttachement" in the test wsdl ( http://
            www.pocketsoap.com/interop/mime-doc.wsdl ) by adding a part
            name ("newBodyName") to soap body part:

            <wsdl:input name="EchoAttachmentInput">
            <mime:multipartRelated>
            <mime:part>
            <soap:body part="newBodyName" use="literal"/>
            </mime:part>
            <mime:part>
            <mime:content part="In" type="application/octetstream"/>
            </mime:part>
            </mime:multipartRelated>
            </wsdl:input>

            do I _need_ to add a corresponding "newBodyName" message
            part like this?:

            <wsdl:message name="EchoAttachmentIn">
            <wsdl:part name="newBodyName" element= "types:toBeDetermined"/>
            <wsdl:part name="In" element="types:EchoAttachment"/> </wsdl:message>

            or can I just leave the single "In" message part like before and
            simply add more elements to the EchoAttachment type like this?:

            <complexType name="EchoAttachment">
            <sequence>
            <element name="foo" type="xsd:string"/>
            <element name="bar" type="xsd:string"/>
            <element name="baz" type="xsd:string"/>
            <element name="timeStamp" type="xsd:dateTime"/>
            <element name="In" type="types:binary"/>
            </sequence>
            </complexType>

            I'm not quite sure which one is right.
            Help completing this test case would be appreciated.

            travis


            --- In soapbuilders@yahoogroups.com, "Wes Moulder" <
            wes@t...> wrote:
            > Rather than a proof of actual use cases, think of the tests as
            proof
            > that systems are able to generate messages that others
            understand.

            > As for MM7, they have to generate the WSDL that puts the parts
            in the
            > appropriate place,



            -----------------------------------------------------------------
            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/
          • travis_atkins <travis_atkins@yahoo.com>
            I had taken a look at the example you mention in the wsdl spec some time ago but it fails to cover exactly the case I _am_ looking to cover, which is the case
            Message 5 of 5 , Feb 5, 2003
            • 0 Attachment
              I had taken a look at the example you mention in the wsdl spec
              some time ago but it fails to cover exactly the case I _am_
              looking to cover, which is the case where the attachments ARE
              referenced in the body.

              So I am still wondering how to modify the doc-literal test case (
              http://www.pocketsoap.com/interop/mime-doc.wsdl ) so that it
              covers the case where the attachments ARE referenced in the
              body (and there are other elements of interest in the return type).

              Does any one know if this is doable via either of the two options I
              outlined in my previous email?

              travis


              --- In soapbuilders@yahoogroups.com, "Wes Moulder" <
              wes@t...> wrote:
              > From the wsdl spec, I'd go with the wsdl segments from
              below:
              >
              > The gist of it is that the return is going to be specified in body,
              with
              > two attachments (unreferenced in the body)
            Your message has been successfully submitted and would be delivered to recipients shortly.