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

RE: [soapbuilders] rpc/literal and wrapped doc-lit

Expand Messages
  • Wes Moulder
    My question wasn t meant as a let s discuss what the schema should look like , I meant it as a question to foster the idea that perhaps these two problems
    Message 1 of 7 , Mar 1, 2002
    • 0 Attachment

      My question wasn’t meant as a “let’s discuss what the schema should look like”, I meant it as a question to foster the idea that perhaps these two problems should be thought about together.  Basically, as I said before, I see two problems here.  We have this unknown, what does “RPC/literal” mean, and we have this dual use of doc/lit for bare and wrapped.  From what I can tell, wrapped matches rpc/literal in spirit, if not in specification.

      I gather from section 7.1 that an rpc call must have the parameters to the method call defined by an “accessor”, but my scan through the soap spec didn’t tell me what an “accessor” was, just that it be related by name to one of the method’s parameters.  If I make a great leap of intuition and say that an accessor is explicitly an element, then I see your argument, that you’re already doing more than what RPC in soap defines.  If I make an equally valid assumption that an accessor is just a schema entry, it could be either an attribute or an element.

      I understand about wanting to reduce the complexity, and not define rpc/literal, as a semantic, but since it already exists as a possibility, and there’s already this rpc style semantic being used in doc/lit, I find it valuable to be able to disambiguate passing a document versus making an rpc call in literal encoding.

       

      --Wes

       

      -----Original Message-----
      From: Alex DeJarnatt [mailto:alexdej@...]
      Sent: Friday, March 01, 2002 2:49 AM
      To: soapbuilders@yahoogroups.com
      Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

       

      I don't think it's necessary to agree on a mechanism for representing a
      method call in terms of schema. I think each endpoint should be free to
      define this mapping as it wishes (and if it wishes). Endpoints won't all
      always be able to agree about whether a given message exchange was a
      "method call" or just moving xml documents back and forth, but they'll
      still all be able to interop all the time.

      Just to clarify what ASP.NET web services does with its "wrapped"
      mode... We provide our customers with a method-based programming model
      (a web service is a collection of web methods). By default, we might
      represent the response from a HelloWorld method in schema as follows:
      <element name="HelloWorldResponse">
      <complexType>
        <sequence>
         <element name="result" type="string"/>
        </sequence>
      </complexType>
      </element>

      However, the customer has the option to completely customize this so
      that the same method response might be represented as follows:
      <element name="HelloWorldResponse">
      <complexType>
        <attribute name="result" type="string"/>
      </complexType>
      </element>

      So maybe HelloWorld wasn't such a great example but hopefully you get
      the point... We don't have a single schema representation for the notion
      of a method call. The mapping between the method description and the
      schema is completely flexible and completely up to the customer.

      I think you're getting at a pretty fundamental question for literal
      interop: is it important that your customer see the same programming
      model as mine does when they interop using our tools? (By programming
      model, I mean method calls vs. document passing, typed objects vs.
      untyped objects vs. xml dom vs. whatever else, parameter order, out
      param vs. return value, etc...). If we think it is important, then I
      guess we should all agree on what a method call looks like in WSDL (and
      call it rpc/literal).

      I believe the choice of programming model on either side of the wire
      should have no bearing on literal interop, so I don't see any reason to
      define an rpc/literal mode.

      alex



      -----Original Message-----
      From: wes_moulder [mailto:wes@...]
      Sent: Thursday, February 28, 2002 10:02 PM
      To: soapbuilders@yahoogroups.com
      Subject: [soapbuilders] rpc/literal and wrapped doc-lit

      So, on the plane trip back home, I started wondering about two great
      mysteries that came up at the soapbuilders conference.  As the title
      suggests, this is about rpc/literal and wrapped doc-lit.  Since we've
      got an unknown style/use combination, why are we overloading doc/lit
      to support the idea of a method call with the wrapped/bare semantics?
      My understanding of rpc is that it's supposed to declare that the
      message in the body is in fact a method call.  Since this is what
      wrapped does as well, why not merge the ideas there, and declare that
      our interpretation of rpc/literal is indeed wrapped doc/lit?
      Is there any technical reason that this should not be done?  (I should
      probably go read the spec to see, but I just got home, and I'm
      exhausted.  I'll do it in the morning if there are no replies.)

      Going forward into SOAP 1.2, is it possible to suggest to the SOAP
      working group that this should be the mapping of that combination (if
      they don't just do away with the literal vs encoding semantics)?  The
      whole idea here is to eliminate the "parameters" hack to figuring out
      which version of doc/lit you're using.

      --Wes



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




      -----------------------------------------------------------------
      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 the Yahoo! Terms of Service.
    • Alex DeJarnatt
      WSDL is more explicit about representing the parameters as elements (I ve quoted the relevant parts of section 3.5 below). I don t understand your comment we
      Message 2 of 7 , Mar 1, 2002
      • 0 Attachment

        WSDL is more explicit about representing the parameters as elements (I’ve quoted the relevant parts of section 3.5 below). 

         

        I don’t understand your comment “we have this dual use of doc/lit for bare and wrapped”.  Bare *is* doc/lit (multiple message parts described by schema) and wrapped is a subset of that (single message part described by schema).  If you understand doc/lit, you can deal with either fine without ever having heard the terms “bare” and “wrapped”.  With rpc/lit we would need to understand a non-schema-based mechanism for formatting a method call as xml (as described by the parts of the WSDL spec I quoted below).  I don’t see how this would help interop or solve any problems.

         

        I hope that didn’t sound pissy.  ;)  This is an interesting discussion…

        thanks

        alex

         

         

        From section 3.5:

         

        If the operation style is rpc each part is a parameter or a return value and appears inside a wrapper element within the body (following Section 7.1 of the SOAP specification). The wrapper element is named identically to the operation name and its namespace is the value of the namespace attribute. Each message part (parameter) appears under the wrapper, represented by an accessor named identically to the corresponding parameter of the call. Parts are arranged in the same order as the parameters of the call.

         

        And also:

        If use is literal, then each part references a concrete schema definition using either the element or type attribute. In the first case, the element referenced by the part will appear directly under the Body element (for document style bindings) or under an accessor element named after the message part (in rpc style). 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). For an example that illustrates defining the contents of a composite Body using a type, see section 2.3.1.  The value of the encodingStyle attribute MAY be used when the use is literal to indicate that the concrete format was derived using a particular encoding (such as the SOAP encoding), but that only the specified variation is supported ("writer makes right").

         

         

         

        -----Original Message-----
        From: Wes Moulder [mailto:wes@...]
        Sent:
        Friday, March 01, 2002 10:29 AM
        To: soapbuilders@yahoogroups.com
        Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

         

        My question wasn’t meant as a “let’s discuss what the schema should look like”, I meant it as a question to foster the idea that perhaps these two problems should be thought about together.  Basically, as I said before, I see two problems here.  We have this unknown, what does “RPC/literal” mean, and we have this dual use of doc/lit for bare and wrapped.  From what I can tell, wrapped matches rpc/literal in spirit, if not in specification.

        I gather from section 7.1 that an rpc call must have the parameters to the method call defined by an “accessor”, but my scan through the soap spec didn’t tell me what an “accessor” was, just that it be related by name to one of the method’s parameters.  If I make a great leap of intuition and say that an accessor is explicitly an element, then I see your argument, that you’re already doing more than what RPC in soap defines.  If I make an equally valid assumption that an accessor is just a schema entry, it could be either an attribute or an element.

        I understand about wanting to reduce the complexity, and not define rpc/literal, as a semantic, but since it already exists as a possibility, and there’s already this rpc style semantic being used in doc/lit, I find it valuable to be able to disambiguate passing a document versus making an rpc call in literal encoding.

         

        --Wes

         

        -----Original Message-----
        From: Alex DeJarnatt [mailto:alexdej@...]
        Sent: Friday, March 01, 2002 2:49 AM
        To: soapbuilders@yahoogroups.com
        Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

         

        I don't think it's necessary to agree on a mechanism for representing a
        method call in terms of schema. I think each endpoint should be free to
        define this mapping as it wishes (and if it wishes). Endpoints won't all
        always be able to agree about whether a given message exchange was a
        "method call" or just moving xml documents back and forth, but they'll
        still all be able to interop all the time.

        Just to clarify what ASP.NET web services does with its "wrapped"
        mode... We provide our customers with a method-based programming model
        (a web service is a collection of web methods). By default, we might
        represent the response from a HelloWorld method in schema as follows:
        <element name="HelloWorldResponse">
        <complexType>
          <sequence>
           <element name="result" type="string"/>
          </sequence>
        </complexType>
        </element>

        However, the customer has the option to completely customize this so
        that the same method response might be represented as follows:
        <element name="HelloWorldResponse">
        <complexType>
          <attribute name="result" type="string"/>
        </complexType>
        </element>

        So maybe HelloWorld wasn't such a great example but hopefully you get
        the point... We don't have a single schema representation for the notion
        of a method call. The mapping between the method description and the
        schema is completely flexible and completely up to the customer.

        I think you're getting at a pretty fundamental question for literal
        interop: is it important that your customer see the same programming
        model as mine does when they interop using our tools? (By programming
        model, I mean method calls vs. document passing, typed objects vs.
        untyped objects vs. xml dom vs. whatever else, parameter order, out
        param vs. return value, etc...). If we think it is important, then I
        guess we should all agree on what a method call looks like in WSDL (and
        call it rpc/literal).

        I believe the choice of programming model on either side of the wire
        should have no bearing on literal interop, so I don't see any reason to
        define an rpc/literal mode.

        alex



        -----Original Message-----
        From: wes_moulder [mailto:wes@...]
        Sent: Thursday, February 28, 2002 10:02 PM
        To: soapbuilders@yahoogroups.com
        Subject: [soapbuilders] rpc/literal and wrapped doc-lit

        So, on the plane trip back home, I started wondering about two great
        mysteries that came up at the soapbuilders conference.  As the title
        suggests, this is about rpc/literal and wrapped doc-lit.  Since we've
        got an unknown style/use combination, why are we overloading doc/lit
        to support the idea of a method call with the wrapped/bare semantics?
        My understanding of rpc is that it's supposed to declare that the
        message in the body is in fact a method call.  Since this is what
        wrapped does as well, why not merge the ideas there, and declare that
        our interpretation of rpc/literal is indeed wrapped doc/lit?
        Is there any technical reason that this should not be done?  (I should
        probably go read the spec to see, but I just got home, and I'm
        exhausted.  I'll do it in the morning if there are no replies.)

        Going forward into SOAP 1.2, is it possible to suggest to the SOAP
        working group that this should be the mapping of that combination (if
        they don't just do away with the literal vs encoding semantics)?  The
        whole idea here is to eliminate the "parameters" hack to figuring out
        which version of doc/lit you're using.

        --Wes



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




        -----------------------------------------------------------------
        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 the Yahoo! Terms of Service.



        -----------------------------------------------------------------
        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 the Yahoo! Terms of Service.
      • Wes Moulder
        Would you agree with me that wrapped is essentially an rpc call, where the name of the root of the document fragment is the method name? While it may not fit
        Message 3 of 7 , Mar 1, 2002
        • 0 Attachment

          Would you agree with me that wrapped is essentially an rpc call, where the name of the root of the document fragment is the method name?  While it may not fit SOAP 1.1, as it seems that 1.1 is too restrictive, it would be nice to separate the concepts explicitly.  It feels like an overloading for doc/lit to me.  (Sending a bare message, you derive the information for dispatching from SOAPAction, or url, or some outside source.  Sending a wrapped message, you derive the information from the root element of the document being sent.  The only way to distinguish between the two types of doc/lit is to look at the name attribute of the message parts, by my understanding. (If I’m wrong here, please correct me, as it will make my life easier.))

          Ideally, the rpc/lit would be wholly driven by schema, with the schema driving the names of the arguments, and their respective locations.  Thus, wrapped mode would stay the same in terms of schema definition, and only the style on the bindings would change to rpc.

          As far as sounding pissy, don’t worry.  It is email, and very hard to express emotions via text.  I hope I don’t sound too argumentative, I am trying to simplify things, and I will admit, I was not quite aware of the explicitness of representing parameters as elements.

          Thanks for helping me clarify this,

          --Wes

           

          -----Original Message-----
          From: Alex DeJarnatt [mailto:alexdej@...]
          Sent: Friday, March 01, 2002 1:26 PM
          To: soapbuilders@yahoogroups.com
          Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

           

          WSDL is more explicit about representing the parameters as elements (I’ve quoted the relevant parts of section 3.5 below). 

           

          I don’t understand your comment “we have this dual use of doc/lit for bare and wrapped”.  Bare *is* doc/lit (multiple message parts described by schema) and wrapped is a subset of that (single message part described by schema).  If you understand doc/lit, you can deal with either fine without ever having heard the terms “bare” and “wrapped”.  With rpc/lit we would need to understand a non-schema-based mechanism for formatting a method call as xml (as described by the parts of the WSDL spec I quoted below).  I don’t see how this would help interop or solve any problems.

           

          I hope that didn’t sound pissy.  ;)  This is an interesting discussion…

          thanks

          alex

           

           

          From section 3.5:

           

          If the operation style is rpc each part is a parameter or a return value and appears inside a wrapper element within the body (following Section 7.1 of the SOAP specification). The wrapper element is named identically to the operation name and its namespace is the value of the namespace attribute. Each message part (parameter) appears under the wrapper, represented by an accessor named identically to the corresponding parameter of the call. Parts are arranged in the same order as the parameters of the call.

           

          And also:

          If use is literal, then each part references a concrete schema definition using either the element or type attribute. In the first case, the element referenced by the part will appear directly under the Body element (for document style bindings) or under an accessor element named after the message part (in rpc style). 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). For an example that illustrates defining the contents of a composite Body using a type, see section 2.3.1.  The value of the encodingStyle attribute MAY be used when the use is literal to indicate that the concrete format was derived using a particular encoding (such as the SOAP encoding), but that only the specified variation is supported ("writer makes right").

           

           

           

          -----Original Message-----
          From: Wes Moulder [mailto:wes@...]
          Sent: Friday, March 01, 2002 10:29 AM
          To: soapbuilders@yahoogroups.com
          Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

           

          My question wasn’t meant as a “let’s discuss what the schema should look like”, I meant it as a question to foster the idea that perhaps these two problems should be thought about together.  Basically, as I said before, I see two problems here.  We have this unknown, what does “RPC/literal” mean, and we have this dual use of doc/lit for bare and wrapped.  From what I can tell, wrapped matches rpc/literal in spirit, if not in specification.

          I gather from section 7.1 that an rpc call must have the parameters to the method call defined by an “accessor”, but my scan through the soap spec didn’t tell me what an “accessor” was, just that it be related by name to one of the method’s parameters.  If I make a great leap of intuition and say that an accessor is explicitly an element, then I see your argument, that you’re already doing more than what RPC in soap defines.  If I make an equally valid assumption that an accessor is just a schema entry, it could be either an attribute or an element.

          I understand about wanting to reduce the complexity, and not define rpc/literal, as a semantic, but since it already exists as a possibility, and there’s already this rpc style semantic being used in doc/lit, I find it valuable to be able to disambiguate passing a document versus making an rpc call in literal encoding.

           

          --Wes

           

          -----Original Message-----
          From: Alex DeJarnatt [mailto:alexdej@...]
          Sent: Friday, March 01, 2002 2:49 AM
          To: soapbuilders@yahoogroups.com
          Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

           

          I don't think it's necessary to agree on a mechanism for representing a
          method call in terms of schema. I think each endpoint should be free to
          define this mapping as it wishes (and if it wishes). Endpoints won't all
          always be able to agree about whether a given message exchange was a
          "method call" or just moving xml documents back and forth, but they'll
          still all be able to interop all the time.

          Just to clarify what ASP.NET web services does with its "wrapped"
          mode... We provide our customers with a method-based programming model
          (a web service is a collection of web methods). By default, we might
          represent the response from a HelloWorld method in schema as follows:
          <element name="HelloWorldResponse">
          <complexType>
            <sequence>
             <element name="result" type="string"/>
            </sequence>
          </complexType>
          </element>

          However, the customer has the option to completely customize this so
          that the same method response might be represented as follows:
          <element name="HelloWorldResponse">
          <complexType>
            <attribute name="result" type="string"/>
          </complexType>
          </element>

          So maybe HelloWorld wasn't such a great example but hopefully you get
          the point... We don't have a single schema representation for the notion
          of a method call. The mapping between the method description and the
          schema is completely flexible and completely up to the customer.

          I think you're getting at a pretty fundamental question for literal
          interop: is it important that your customer see the same programming
          model as mine does when they interop using our tools? (By programming
          model, I mean method calls vs. document passing, typed objects vs.
          untyped objects vs. xml dom vs. whatever else, parameter order, out
          param vs. return value, etc...). If we think it is important, then I
          guess we should all agree on what a method call looks like in WSDL (and
          call it rpc/literal).

          I believe the choice of programming model on either side of the wire
          should have no bearing on literal interop, so I don't see any reason to
          define an rpc/literal mode.

          alex



          -----Original Message-----
          From: wes_moulder [mailto:wes@...]
          Sent: Thursday, February 28, 2002 10:02 PM
          To: soapbuilders@yahoogroups.com
          Subject: [soapbuilders] rpc/literal and wrapped doc-lit

          So, on the plane trip back home, I started wondering about two great
          mysteries that came up at the soapbuilders conference.  As the title
          suggests, this is about rpc/literal and wrapped doc-lit.  Since we've
          got an unknown style/use combination, why are we overloading doc/lit
          to support the idea of a method call with the wrapped/bare semantics?
          My understanding of rpc is that it's supposed to declare that the
          message in the body is in fact a method call.  Since this is what
          wrapped does as well, why not merge the ideas there, and declare that
          our interpretation of rpc/literal is indeed wrapped doc/lit?
          Is there any technical reason that this should not be done?  (I should
          probably go read the spec to see, but I just got home, and I'm
          exhausted.  I'll do it in the morning if there are no replies.)

          Going forward into SOAP 1.2, is it possible to suggest to the SOAP
          working group that this should be the mapping of that combination (if
          they don't just do away with the literal vs encoding semantics)?  The
          whole idea here is to eliminate the "parameters" hack to figuring out
          which version of doc/lit you're using.

          --Wes



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



          -----------------------------------------------------------------
          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 the Yahoo! Terms of Service.

           

          -----------------------------------------------------------------
          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 the Yahoo! Terms of Service.



          -----------------------------------------------------------------
          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 the Yahoo! Terms of Service.
        • Alex DeJarnatt
          I agree that what we call doc/lit/wrapped models the input and output of a method as schema, though way more flexibly than is allowed by wsdl for rpc/literal.
          Message 4 of 7 , Mar 1, 2002
          • 0 Attachment

            I agree that what we call doc/lit/wrapped models the input and output of a method as schema, though way more flexibly than is allowed by wsdl for rpc/literal.  However, I do not agree that wrapped is an rpc call, since this implies that both sides of the wire agree that a method is being called.  With our wrapped, the asp.net side can treat the message exchange as a method call and the other side can treat it as anything it wants. 

             

            About the routing, I don’t see that the service has to route doc/lit messages differently based on whether they’re “wrapped” or “bare” (at least we don’t).  However, it is necessary to have enough information to do the routing by operation for a given service. If you don’t have enough information in the body of the message (for instance two messages have identical schema), you’d need to rely on some external information such as soap action or a header.  In asp.net web services we can route by soap action or by the qname of the first child of body. The meaning of this name to the service might vary by bare vs. wrapped but how we route doesn’t. 

             

            Hope this helps..

            alex

             

            -----Original Message-----
            From: Wes Moulder [mailto:wes@...]
            Sent:
            Friday, March 01, 2002 12:23 PM
            To: soapbuilders@yahoogroups.com
            Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

             

            Would you agree with me that wrapped is essentially an rpc call, where the name of the root of the document fragment is the method name?  While it may not fit SOAP 1.1, as it seems that 1.1 is too restrictive, it would be nice to separate the concepts explicitly.  It feels like an overloading for doc/lit to me.  (Sending a bare message, you derive the information for dispatching from SOAPAction, or url, or some outside source.  Sending a wrapped message, you derive the information from the root element of the document being sent.  The only way to distinguish between the two types of doc/lit is to look at the name attribute of the message parts, by my understanding. (If I’m wrong here, please correct me, as it will make my life easier.))

            Ideally, the rpc/lit would be wholly driven by schema, with the schema driving the names of the arguments, and their respective locations.  Thus, wrapped mode would stay the same in terms of schema definition, and only the style on the bindings would change to rpc.

            As far as sounding pissy, don’t worry.  It is email, and very hard to express emotions via text.  I hope I don’t sound too argumentative, I am trying to simplify things, and I will admit, I was not quite aware of the explicitness of representing parameters as elements.

            Thanks for helping me clarify this,

            --Wes

             

            -----Original Message-----
            From: Alex DeJarnatt [mailto:alexdej@...]
            Sent:
            Friday, March 01, 2002 1:26 PM
            To: soapbuilders@yahoogroups.com
            Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

             

            WSDL is more explicit about representing the parameters as elements (I’ve quoted the relevant parts of section 3.5 below). 

             

            I don’t understand your comment “we have this dual use of doc/lit for bare and wrapped”.  Bare *is* doc/lit (multiple message parts described by schema) and wrapped is a subset of that (single message part described by schema).  If you understand doc/lit, you can deal with either fine without ever having heard the terms “bare” and “wrapped”.  With rpc/lit we would need to understand a non-schema-based mechanism for formatting a method call as xml (as described by the parts of the WSDL spec I quoted below).  I don’t see how this would help interop or solve any problems.

             

            I hope that didn’t sound pissy.  ;)  This is an interesting discussion…

            thanks

            alex

             

             

            From section 3.5:

             

            If the operation style is rpc each part is a parameter or a return value and appears inside a wrapper element within the body (following Section 7.1 of the SOAP specification). The wrapper element is named identically to the operation name and its namespace is the value of the namespace attribute. Each message part (parameter) appears under the wrapper, represented by an accessor named identically to the corresponding parameter of the call. Parts are arranged in the same order as the parameters of the call.

             

            And also:

            If use is literal, then each part references a concrete schema definition using either the element or type attribute. In the first case, the element referenced by the part will appear directly under the Body element (for document style bindings) or under an accessor element named after the message part (in rpc style). 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). For an example that illustrates defining the contents of a composite Body using a type, see section 2.3.1.  The value of the encodingStyle attribute MAY be used when the use is literal to indicate that the concrete format was derived using a particular encoding (such as the SOAP encoding), but that only the specified variation is supported ("writer makes right").

             

             

             

            -----Original Message-----
            From: Wes Moulder [mailto:wes@...]
            Sent:
            Friday, March 01, 2002 10:29 AM
            To: soapbuilders@yahoogroups.com
            Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

             

            My question wasn’t meant as a “let’s discuss what the schema should look like”, I meant it as a question to foster the idea that perhaps these two problems should be thought about together.  Basically, as I said before, I see two problems here.  We have this unknown, what does “RPC/literal” mean, and we have this dual use of doc/lit for bare and wrapped.  From what I can tell, wrapped matches rpc/literal in spirit, if not in specification.

            I gather from section 7.1 that an rpc call must have the parameters to the method call defined by an “accessor”, but my scan through the soap spec didn’t tell me what an “accessor” was, just that it be related by name to one of the method’s parameters.  If I make a great leap of intuition and say that an accessor is explicitly an element, then I see your argument, that you’re already doing more than what RPC in soap defines.  If I make an equally valid assumption that an accessor is just a schema entry, it could be either an attribute or an element.

            I understand about wanting to reduce the complexity, and not define rpc/literal, as a semantic, but since it already exists as a possibility, and there’s already this rpc style semantic being used in doc/lit, I find it valuable to be able to disambiguate passing a document versus making an rpc call in literal encoding.

             

            --Wes

             

            -----Original Message-----
            From: Alex DeJarnatt [mailto:alexdej@...]
            Sent:
            Friday, March 01, 2002 2:49 AM
            To: soapbuilders@yahoogroups.com
            Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

             

            I don't think it's necessary to agree on a mechanism for representing a
            method call in terms of schema. I think each endpoint should be free to
            define this mapping as it wishes (and if it wishes). Endpoints won't all
            always be able to agree about whether a given message exchange was a
            "method call" or just moving xml documents back and forth, but they'll
            still all be able to interop all the time.

            Just to clarify what ASP.NET web services does with its "wrapped"
            mode... We provide our customers with a method-based programming model
            (a web service is a collection of web methods). By default, we might
            represent the response from a HelloWorld method in schema as follows:
            <element name="HelloWorldResponse">
            <complexType>
              <sequence>
               <element name="result" type="string"/>
              </sequence>
            </complexType>
            </element>

            However, the customer has the option to completely customize this so
            that the same method response might be represented as follows:
            <element name="HelloWorldResponse">
            <complexType>
              <attribute name="result" type="string"/>
            </complexType>
            </element>

            So maybe HelloWorld wasn't such a great example but hopefully you get
            the point... We don't have a single schema representation for the notion
            of a method call. The mapping between the method description and the
            schema is completely flexible and completely up to the customer.

            I think you're getting at a pretty fundamental question for literal
            interop: is it important that your customer see the same programming
            model as mine does when they interop using our tools? (By programming
            model, I mean method calls vs. document passing, typed objects vs.
            untyped objects vs. xml dom vs. whatever else, parameter order, out
            param vs. return value, etc...). If we think it is important, then I
            guess we should all agree on what a method call looks like in WSDL (and
            call it rpc/literal).

            I believe the choice of programming model on either side of the wire
            should have no bearing on literal interop, so I don't see any reason to
            define an rpc/literal mode.

            alex



            -----Original Message-----
            From: wes_moulder [mailto:wes@...]
            Sent:
            Thursday, February 28, 2002 10:02 PM
            To: soapbuilders@yahoogroups.com
            Subject: [soapbuilders] rpc/literal and wrapped doc-lit

            So, on the plane trip back home, I started wondering about two great
            mysteries that came up at the soapbuilders conference.  As the title
            suggests, this is about rpc/literal and wrapped doc-lit.  Since we've
            got an unknown style/use combination, why are we overloading doc/lit
            to support the idea of a method call with the wrapped/bare semantics?
            My understanding of rpc is that it's supposed to declare that the
            message in the body is in fact a method call.  Since this is what
            wrapped does as well, why not merge the ideas there, and declare that
            our interpretation of rpc/literal is indeed wrapped doc/lit?
            Is there any technical reason that this should not be done?  (I should
            probably go read the spec to see, but I just got home, and I'm
            exhausted.  I'll do it in the morning if there are no replies.)

            Going forward into SOAP 1.2, is it possible to suggest to the SOAP
            working group that this should be the mapping of that combination (if
            they don't just do away with the literal vs encoding semantics)?  The
            whole idea here is to eliminate the "parameters" hack to figuring out
            which version of doc/lit you're using.

            --Wes



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



            -----------------------------------------------------------------
            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 the Yahoo! Terms of Service.

             

            -----------------------------------------------------------------
            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 the Yahoo! Terms of Service.



            -----------------------------------------------------------------
            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 the Yahoo! Terms of Service.



            -----------------------------------------------------------------
            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 the Yahoo! Terms of Service.
          Your message has been successfully submitted and would be delivered to recipients shortly.