Re: Issue 195: slightly updated simple proposal

 Gudge, 
 the problem is we're saying an RPC result is a struct (or array, 
but it's analogous). We can put some information in the struct, 
which would get serialized according to the SOAP Encoding rules, 
but we cannot extend the rules.
 It would be possible if we didn't make RPC based on SOAP 
Data Model but on infoset instead, with parameters possibly 
encoded (and indicating that with the encodingStyle attribute). 
 We'd have no problem then with ordering, with using attributes 
or any other funkiness, but we cannot do that in SOAP Data Model. 
It was decided last fall that RPC would stay based on the Data 
Model.
 Or we could create an extended data model allowing metadata on 
edges and an extended encoding serializing the metadata as 
attributes and make RPC result be such a metadata-enhanced 
struct.
 Anyway, I dislike the idea of writing a strict XML Schema schema
for SOAP Encoding data and then treating that as a SOAP Data
Model schema. 
 1) You can have a strict schema for SOAP Encoding data which
will allow invalid serializations but also all valid ones for a
given Data Model schema; 2) you can have a strict schema for SOAP
Encoding data which will only allow some valid serializations of
instances of a given Data Model schema, 3) or you can have an XML
Schema schema that you translate into a Data Model schema and
then forget. You probably could do a combination of the second
and the third, but I feel this would be quite complex to
implement.
 In WSDL, there are two possibilities - plain old XML strictly
according to a given XML Schema schema, or the third option
above. It is easy to imagine simple addition to WSDL that would 
allow rpc:result element for the return value to be described 
using XML Schema schemata without anyone touching our namespace.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Wed, 24 Apr 2002, Martin Gudgin wrote:

 > 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 15:18:17 UTC