RE: [soapbuilders] Proposal for naming the SOAP RPC return value

hi there

if the response is serialized just like a NULL return value, doesn't this
mean that you should put xsi:nil='1' in the response?

to me, returning void means "i am not designed to return anything", whereas
returning nil means "i return something, and in this case, it's nil".

i think that returning nil is different from returning void and should be
represented differently.

comments?

cheers, graham

  -----Original Message-----
  From: Jacek Kopecky [mailto:jacek@idoox.com]
  Sent: Friday, August 17, 2001 5:08 PM
  To: xml-dist-app@w3.org; SOAP@DISCUSS.DEVELOP.COM;
soapbuilders@yahoogroups.com
  Cc: frankd@tibco.com
  Subject: [soapbuilders] Proposal for naming the SOAP RPC return value


  Hello all. 8-)
  The RPC Task Force has considered the issues #16 [1] and #113
  [2] and the feedback to the message [3] in the soapbuilders' list
  (summarized in [4]) and proposes the following rewording of the
  appropriate three bullets in SOAP version 1.2 section 7.1 [5]
  (editors' draft) and adding the following examples and the ending
  note.
  This proposal is based on solution #3 from the message [4] but
  it solves the possibility of naming conflicts.


  -------------------------- proposal begins

  - An RPC response is modeled as a struct.
  - The response is viewed as a single struct containing an
  accessor for the return value and each [out] or [in/out]
  parameter. The accessors for the parameters SHOULD be in the same
  order as in the procedure or method signature, with the return
  value accessor being the first.
  - Each parameter accessor has a name corresponding to the name of
  the parameter and type corresponding to the type of the parameter.
  The name of the return value accessor is "result" and it is
  namespace-qualified with the namespace identifier
  "http://www.w3.org/2001/06/rpc". The name of the struct is not
  significant. However, a convention is to name it after the
  procedure or method name with the string "Response" appended.


  An example of an envelope with a simple successful RPC response:

  <env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
    <env:Body>
      <m:GetLastTradePriceResponse
            env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
            xmlns:m="http://example.org/2001/06/quotes"
            xmlns:r="http://www.w3.org/2001/06/rpc">
        <r:result>34.1</r:result>
      </m:GetLastTradePriceResponse>
    </env:Body>
  </env:Envelope>

  An example of an envelope with a successful RPC response of a
  void procedure with no [in/out] or [out] parameters:

  <env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
    <env:Body>
      <m:SetDateResponse
           env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
           xmlns:m="http://example.org/2001/06/clock" >
      </m:SetDateResponse>
    </env:Body>
  </env:Envelope>

  An example of an envelope with a successful RPC response of a
  procedure with a return value and an [out] parameter:

  <env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
    <env:Body>
      <m:GetLastTradePriceResponse
            env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
            xmlns:m="http://example.org/2001/06/quotes"
            xmlns:r="http://www.w3.org/2001/06/rpc">
        <r:result>34.1</r:result>
        <StockName>Foo, inc.</StockName>
      </m:GetLastTradePriceResponse>
    </env:Body>
  </env:Envelope>

  An example of an envelope with a successful RPC response of a
  procedure with no return value and two [out] parameters:

  <env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
    <env:Body>
      <m:GetLastTradePriceResponse
            env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
            xmlns:m="http://example.org/2001/06/quotes"
            xmlns:r="http://www.w3.org/2001/06/rpc">
        <Price>34.1</Price>
        <StockName>Foo, inc.</StockName>
      </m:GetLastTradePriceResponse>
    </env:Body>
  </env:Envelope>


  Please note that according to the SOAP Encoding rules [6], rule
  no. 9 (the very last in section 5.1), a procedure with a void
  return type is serialized equally to a procedure with a non-void
  return type but with a NULL return value.

  -------------------------- proposal ends

  This proposal directly resolves issues #16 and #113.

  We believe that this proposal is fully consistent with the
  encoding rules of SOAP section 5.

  The RPC Task force is likely to put this proposal forward to the
  XMLP Working Group for decision, and so your feedback can make a
  difference.

  Please send your replies to the list xml-dist-app@w3.org.

  As usual, we will take silence for assent after a reasonable
  time so please voice your opinion soon.


                              Jacek Kopecky

                              Idoox
                              http://www.idoox.com/


  [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x16
  [2] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x113
  [3] http://groups.yahoo.com/group/soapbuilders/message/4907
  [4] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0131.html
  [5] http://www.w3.org/TR/2001/WD-soap12-20010709/#_Toc478383533
  [6] http://www.w3.org/2000/xp/Group/1/06/01/soap-02-infoset.html#encrules


        Yahoo! Groups Sponsor



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