Re: Issue 195: slightly updated simple proposal

I don't see why we don't just define an attribute in the soap-rpc namespace
and have people put that on the return value. IN our encoding it would mean
putting it on the serialization of an inbound edge for the node which is the
return value. e.g.;

<s:Envelope xmlns:s='http://www.w3.org/2001/12/soap-envelope'
            xmlns:r='http://www.w3.org/2001/12/soap-rpc' >
  <s:Body>
    <m:MethodResponse
s:encodingStyle='http://www.w3.org/2001/12/soap-encoding'
                      xmlns:m='http://example.org/methods' >
      <m:someoutparam>10</m:someoutparam>
      <m:someotheroutparam r:return='true' >20</m:someotheroutparam>
      <m:yetanotheroutparam>30</m:yetanotheroutparam>
    </m:Method>
  </s:Body>
</s:Envelope>

This

a) decouples the notion of return value from the notion of the graph
b) decouples return value from the encoding
c) allows people to treat any parameter as the return value
d) makes describing void methods very simple
e) allows people that use other encodings to use the same attribute
f) allows people that use no encoding to use the same attribute
g) allows people that describe methods using XML Schema to use the same
attribute
h) allows those same people to reference the attribute in the rpc schema.

Rpc schema would look like this;

<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'
           targetNamespace='http://www.w3.org/2001/12/soap-rpc' >
  <xs:attribute name='return'>
    <xs:simpleType>
      <xs:restriction base='xs:boolean' >
        <xs:pattern value='1|true' />
      </xs:restriction>
    </xs:simpleType>
  </xs:attribute>
</xs:schema>

Gudge



----- Original Message -----
From: "Jacek Kopecky" <jacek@systinet.com>
To: "Ray Whitmer" <rayw@netscape.com>
Cc: <xml-dist-app@w3.org>
Sent: Wednesday, April 24, 2002 10:43 AM
Subject: Re: Issue 195: slightly updated simple proposal


> Ray,
>  my proposal below resolves issue 195 saying that we don't think
> mandating the full qualified name of the return value is a bad
> idea. I don't think that the resolution must necessarily agree
> with the issue originator.
>  But there is still my other proposal (the full [1]) where I
> suggest we remove the notion of return value altogether, moving
> it into the application domain. I don't think I've heard many
> opinions against it.
>  Best regards,
>
>                    Jacek Kopecky
>
>                    Senior Architect, Systinet (formerly Idoox)
>                    http://www.systinet.com/
>
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0113.html
>
>
> On Tue, 23 Apr 2002, Ray Whitmer wrote:
>
>  > Since there has been apparently no more recent discussion, I will
>  > comment on this proposal.
>  >
>  > This apparently does nothing whatsoever to resolve issue 195.  I find
>  > issue 195 to be a real concern.  I think it should be possible to use
>  > schema to accurately describe simple RPC calls.  If a struct has been
>  > chosen as the return vehicle, then if a fixed name with a fixed type is
>  > required, this is not possible.
>  >
>  > There is nothing in the charter or in the requirements that lead me to
>  > believe that it is essential to know without knowing the method
>  > signature that a particular return value is a special unnamed return,
>  > which a language may or may not support.  There are so many other
things
>  > that the binding is expected to understand or map arbitrarily, and SOAP
>  > 1.2 has made this worse by making both a struct and an array as options
>  > because now every language, whether it supports named or positional
>  > arguments has to support calls that will be of the other type just
>  > because someone decided they should be.
>  >
>  > How about the following language instead:
>  >
>  >  * In the struct representation of the response, the label of the
>  > unnamed return value outbound edge is the one which does not
>  > correspond to any of the named out or in/out parameters.
>  >
>  > In most languages you have to know the names of the parameters anyway,
>  > so they can be associated with positions, since few languages associate
>  > by name.  This way, the result is given a meaningful name and type,
>  > which is good for a variety of reasons.  This is also no worse than the
>  > case of a returned array where you do not know whether or not there is
a
>  > return value unless you know the signature and binding.
>  >
>  > Ray Whitmer
>  > rayw@netscape.com
>  >
>  >
>  > Jacek Kopecky wrote:
>  >
>  > > Hi all, 8-)
>  > > this is the first part of my former proposal [1], updated a
>  > >little and standing on its own so it's not so confusing.
>  > > In short, the update removes the mandatory presence or absence
>  > >of the return value in the struct representation, it adds a note
>  > >about the array representation, and it does some rephrasing in
>  > >places.
>  > > The proposal:
>  > >
>  > > It needs to be clarified that in the array representation of RPC
>  > >result the return value is not named rpc:result (because as we
>  > >cannot specify positions in structs, we cannot specify names in
>  > >arrays). Therefore I propose the fifth bullet to be changed to:
>  > >
>  > > * The response is viewed as a single struct or array containing
>  > >an outbound edge for the return value and each [out] or [in/out]
>  > >parameter. If the response is an array, the return value edge
>  > >MUST be the first edge in the array.
>  > >
>  > > And the sixth bullet in the RPC Body section - 4.1 [1] - should
>  > >be split into:
>  > >
>  > > * Each outbound edge has a label corresponding to the name of
>  > >the parameter (see A Mapping Application Defined Name to XML
>  > >Name) or a position corresponding to the position of the
>  > >parameter.
>  > >
>  > > * In the struct representation of the response, the label of the
>  > >return value outbound edge is "result" and it is
>  > >namespace-qualified with the namespace name
>  > >"http://www.w3.org/2001/12/soap-rpc".
>  > >
>  > > * In the array representation of the response, the return value
>  > >outbound edge is the first member of the array if the return
>  > >value of the procedure is non-void. If the return value of the
>  > >procedure is void, the first edge is the first [out] or [in/out]
>  > >parameter.
>  > > Note: in case the application designers only know the format of
>  > >the messages, they are free to choose to treat the first out
>  > >parameter as a return value or as the first out parameter.
>  > >
>  > > The note should probably go somewhere else than in the bullet,
>  > >but I don't know where, really.
>  > >
>  > >                   Jacek Kopecky
>  > >
>  > >                   Senior Architect, Systinet (formerly Idoox)
>  > >                   http://www.systinet.com/
>  > >
>  > >
>  > >
>  > >[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0113.html
>  > >
>  > >
>  >
>  >
>
>

Received on Wednesday, 24 April 2002 11:48:14 UTC