Re: Issue 195: soap-rpc:result

 Herve,
 I'll comment on the main issue 195 because Ray and me are going 
to present a proposal for the minor issue soon.
 
 Many people have expressed concern with the return value not 
being easily describable with XML Schema. My short answer is: XML 
Schema is not suitable for describing data in SOAP Data Model (or 
at least in SOAP Encoding).

 My explanation:

 In SOAP 1.1, the return value accessor was to be the first one 
in the result struct, its name being insignificant. This is an 
inconsistent approach to structs because in the data model there 
is no ordering in structs. So we can do one of the following:

 1) specify a name for the return value accessor,
 2) remodel the RPC response as something different than a 
struct,
 3) remove the notion of an unnamed return value.

 I don't think we ever discussed option 3. I suggested option 2 a 
long time ago in the RPC TF and we decided against. That leaves 
us with option 1.

 The name of an accessor has two parts - namespace name and 
local name. We could have only specified the local name but we 
would have to deal with possible conflicts, for example

 "The return value accessor's local name is 'SOAP-RPC-result'. If 
there is a parameter on this procedure that's called the same, 
its name must be changed."

 Even though this approach might work, it's not pretty. 

 Namespaces are meant to help avoid conflicts so we decided to 
make the element namespace-qualified. Remember, this is SOAP 
level, not WSDL. Languages like WSDL can handle this situation by 
specifying, for example, the name of the return value message 
part, which in the actual SOAP message will then be named 
rpc:result.

 It is a known fact that SOAP Encoding data is not sufficiently 
describable by XML Schema. It is true that WSDL uses tricks to be 
able to do it nevertheless, but it shouldn't complain when it has 
to have another trick like the one I suggested above. BT, I'm 
also on the WS-Description WG.

 Best regards,
 

                   Jacek Kopecky

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



On Wed, 27 Mar 2002, Herve Ruellan wrote:

 > All,
 > 
 > Minor Issue
 > ===========
 > Looking more in depth at issue 195, I caught what seems to me a small 
 > discrepancy in the spec:
 > 
 > section 3.1.3, point 2, second bullet states:
 > <quote>
 > If outbound edges are distinguished only by position ("array") then the 
 > local name and namespace name properties of the element information item 
 > are not significant.
 > </quote>
 > 
 > section 4.1, sixth bullet states:
 > <quote>
 > 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. The label of 
 > the return value outbound edge is "result" and it is namespace-qualified 
 > with the namespace name "http://www.w3.ort/2001/12/soap-rpc"...
 > </quote>
 > 
 > As an RPC response can be viewed as an array, when it is the case, I 
 > don't think we should mandate any specific local name and namespace for 
 > the element information item representing the return value outbound 
 > edge. (Note: rereading this, I'm not sure we really mandate the local 
 > name and namespace in all cases, but I think that at least we could make 
 > the prose clearer).
 > 
 > I would propose to change the text for the return value in order to have 
 > it in sync with the text for input or output parameters, that is if a 
 > label is needed here is the definition otherwise, just use the position.
 > 
 > Main Issue of 195
 > =================
 > Going back to the issue raised by Tim Ewald, I think we should not 
 > mandate the namespace for the return value outbound edge.
 > By removing this, we allow application developpers using SOAP to write 
 > XML Schema representing an RPC invocation and an RPC response, enabling 
 > them to Schema validate the RPC invocation or RPC response if they want.
 > 
 > However, we don't want to mandate Schema validation with SOAP. So I 
 > don't think we should speak of types for RPC parameters.
 > 
 > Proposal
 > ========
 > As a resolution for 195, I would propose to change the sixth bullet of 
 > section 4.1 to reflect those thought.
 > 
 > <original>
 > 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. 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". The return 
 > value outbound edge MUST be present if the return value of the procedure 
 > is non-void. The return value outbound edge MUST NOT be present if the 
 > return value of the procedure is void.
 > </original>
 > 
 > <proposal>
 > Each outbound edge >>>either<<< 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. >>>If needed, 
 > the label of the return value outbound edge is "result"<<<. The return 
 > value outbound edge MUST be present if the return value of the procedure 
 > is non-void. The return value outbound edge MUST NOT be present if the 
 > return value of the procedure is void.
 > </proposal>
 > 
 > Comments ?
 > 
 > Hervé.
 >

Received on Wednesday, 3 April 2002 07:25:49 UTC