W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2002

Proposal for resolving issue 180

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Tue, 19 Feb 2002 15:25:01 -0800
Message-ID: <79107D208BA38C45A4E45F62673A434D067C8202@red-msg-07.redmond.corp.microsoft.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:06 GMT