Re: Issue 195: soap-rpc:result

Jacek,

Overall I agree with your analysis, but having a different point of view 
I don't reach the same conclusion :-).

My short reply to your short answer is: XML Schema is not suitable for 
describing data in SOAP Data Model (or at least in SOAP Encoding), but 
with a few tweaking, we should be able to used XML Schema to describe 
data in SOAP Encoding for RPC requests and responses.

I see three solutions:

1)
We only specify the local name of the accessor for the return value.

I agree that this might raise conflicts, but it is a compromise and as 
such it is not a perfect solution.

This local name can be:
- 'result'
- <remote procedure name>-result
or anything similar.

2)
We do not specify the local name nor the namespace of the accessor for 
the return value. Both are specified in the same place as the name of 
the input and output parameters of the remote procedure.

3)
RPC requests can be modeled as an array. If we change the spec and say 
that in this case the namespace and local name of the accessor for the 
return value are not specified, but that the return value is the first 
element of the array, then there is no problem describing an RPC 
response with XML Schema when it is modeled as an array.



As a conclusion, I think we almost have 3, so I would really like to 
have it fully. I think that 2 would provide another nice solution, so it 
would be nice to have it too. I agree that 1 is not pretty, but if we 
don't have 2, I would prefer having 1 rather than having nothing.

Regards,

Hervé.

Jacek Kopecky wrote:
>  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/
> 
> 
>

Received on Wednesday, 3 April 2002 10:19:11 UTC