- From: Jacek Kopecky <jacek@systinet.com>
- Date: Tue, 12 Feb 2002 11:16:06 +0100 (CET)
- To: Martin Gudgin <marting@develop.com>
- cc: XML Protocol Discussion <xml-dist-app@w3.org>
Gudge,
the original wording was that the parameters appear in the same
order as in the function signature and that the return value
accessor MUST be first. We cought that MUST in the RPC task force
when we decided that the RPC element is modeled as a struct and
that the return value accessor has a special name. The SHOULD is
there to keep continuity.
Now you caught that there is another, implied, MUST in the words
"these appear in the same order ...", which I think we would have
weakened to a SHOULD, too, if we caught it first in the RPCTF.
We can try and remove the ordering stuff altogether but I think
that what I suggest in the paragraph above is a satisfactory
solution which keeps as much of the SOAP/1.1 rules as acceptable.
What do others think?
Jacek Kopecky
Senior Architect, Systinet (formerly Idoox)
http://www.systinet.com/
On Fri, 8 Feb 2002, Martin Gudgin wrote:
> 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.
>
> Gudge
>
> [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
>
Received on Tuesday, 12 February 2002 05:16:10 UTC