Issue 180: Parameter ordering

Issue 180 [3] states that:
In the editors copy of Part 2[1], section 4.1[2] states of [in] and
[in/out] parameters in the request that; 'These appear in the same order as
in the procedure or method signature.' For [out] and [in/out] parameters in
the response it states; 'The return value accessor SHOULD be first,
followed by the accessors for the parameters which SHOULD be in the same
order as they appear in the procedure or method signature.' Why the
inconsistency? I think we should say the same thing for both request and
response. I don't have a *strong* opinion about whether we should enforce
order or not, but I'd tend to lean toward lining up the response
description with the description of the request.

Discussion:
Two conventions are required for argument signatures. The first is based on
an argument naming convention where each argument is assigned a unique name
e.g "PayrollNumber = ABCD1234". The second convention uses the variable
argument notation commonly found in programming languages e.g. arg[]. Both
conventions may be supported wihin SOAP using a struct for the first and an
array for the second.

Proposal:
The bulleted list in section 4.1 RPC and SOAP Body is rewritten as
   An RPC invocation is modeled as a struct where access uses parameter
   names or as an array where access is by parameter position.
   The invocation is viewed as a single struct or array containing an
   accessor for each [in] or [in/out] parameter. The struct is both named
   and typed identically to the procedure or method name (see A Mapping
   Application Defined Name to XML Name).
   Each [in] or [in/out] parameter is viewed as an accessor, with a name or
   position corresponding to the parameter and type corresponding to the
   type of the parameter (see A Mapping Application Defined Name to XML
   Name). These appear in the same order as in the procedure or method
   signature.
   An RPC response is modeled as a struct where access uses parameter names
   or as an array where access is by parameter position.
   The response is viewed as a single struct or array containing an
   accessor for the return value and each [out] or [in/out] parameter. The
   return value accessor SHOULD be first, followed by the accessors for the
   parameters which SHOULD be in the same order as they appear in the
   procedure or method signature.
   Each parameter accessor has a name or position corresponding to the
   parameter (see A Mapping Application Defined Name to XML Name) 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/12/soap-rpc" The return value
   accessor MUST be present if the return value of the procedure is
   non-void. The return value accessor MUST NOT be present if the return
   value of the procedure is void.
   Invocation faults are handled according to the rules in 4.3 RPC Faults.
   If a protocol binding adds additional rules for fault expression, those
   MUST also be followed.

[1] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.xml
[2] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.xml#IDAGG5CF
[3] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x180

John

Emerging ebusiness Industry Architecture ,
XML Technology and Messaging,
IBM UK Ltd, Hursley Park,
Winchester, SO21 2JN

Tel: (work) +44 (0)1962 815188        (home) +44 (0)1722 781271
Fax: +44 (0)1962 816898
Notes Id: John Ibbotson/UK/IBM
email: john_ibbotson@uk.ibm.com

Received on Monday, 4 March 2002 06:40:10 UTC