- From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Date: Tue, 19 Feb 2002 15:25:01 -0800
- To: <xml-dist-app@w3.org>
The ETF has discussed issue 180 [1] and here is a write-up of the issue, the discussion, and the ETF recommendation. As always, if I have left things out or misinterpreted stuff then please let me know! ISSUE ----- Title: Parameter ordering in Section 4.1 Description: 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 ---------- The group considered the following three options: A) Define some model for method calls and responses Provide a model for what a method call is that allows us to talk about ordering to the degree that we can remove the inconsistency currently found in the text [2]: "These >>SHOULD<< appear in the same order as in the procedure or method signature." for invocation and "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" for responses. B) Don't model calls/responses but say the same thing about ordering for both calls and responses Don't actually provide a model for what a method call is but make the wording consistent in the text [2]: "These >>SHOULD<< appear in the same order as in the procedure or method signature." for invocation and "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" for responses. C) Don't model calls/responses and leave ordering up to others Say that the concept of a method signature is out of scope of SOAP. That is, ordering might or might not significant but SOAP has nothing to say about this issue. All SOAP provides is how to represent call data as a struct. If there are ordering constraints then they may be described in some manner external to SOAP, for example using WSDL. RECOMMENDATION -------------- The ETF recommends that we go with C) as this seems consistent with structs. PROPOSED TEXT ------------- Note that the ETF does NOT recommend any specific text changes. The following changes are my strawperson proposal for incorporating the recommendation into the spec. It consists of three parts: 1) In part 2, section 4.1 [2], for requests, replace "Each [in] or [in/out] parameter is viewed as an accessor, with a name corresponding to the name of 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." With "Each [in] or [in/out] parameter is viewed as an accessor, with a name corresponding to the name of the parameter and type corresponding to the type of the parameter (see A Mapping Application Defined Name to XML Name)." 2) In part 2, section 4.1 [2], for responses, replace "The response is viewed as a single struct 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." With "The response is viewed as a single struct containing an accessor for the return value and each [out] or [in/out] parameter." 3) Maybe add a note to section 3.5 in the description of structs: Note that the SOAP data model does not indicate whether the order of accessors in a struct is significant or not. While other mechanisms can be used to describe such information, it is out of scope of the SOAP data model. Comments? Henrik Frystyk Nielsen mailto:henrikn@microsoft.com [1] http://www.w3.org/2000/xp/Group/xmlp-issues#x180 [2] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#NA6F [3] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#compoundtypes
Received on Tuesday, 19 February 2002 18:26:09 UTC