- From: Pete Hendry <peter.hendry@capeclear.com>
- Date: Wed, 17 Apr 2002 00:52:34 +1200
- To: Jacek Kopecky <jacek@systinet.com>
- CC: xml-dist-app@w3.org
>If we specify only the local name, there will be two levels of >possible conflicts. Let's say we mandate that the local name of >the return value edge is 'result'. > The first conflict: what if we want to have a parameter called >result? > Possible solution - the language binding can translate the name >to _result and add an underscore in front of any other parameter >name that starts with it. So "void foo(int result, int _other)" >would result in a message with parameters named _result and >__other. > Not very practical obviously. I am reading from the latest draft and it specifies the return value MUST be called 'rpc:result' which makes more sense than local name only. > > The second conflict - if we have the contract specified in XML >Schema (or other XML schema language as opposed to specifying the >procedure signature), and we have two elements in the result >struct: > <m:fooResult xmlns:m="urn:foo"> > <a:result xmlns:a="urn:a"/> > <b:result xmlns:b="urn:b"/> > </m:fooResult> > This does not address the issue of the return value but a more general issue of whether duplicate names in a struct will be supported (with different namespaces). There should be nothing wrong with defining <m:fooResult xmlns:m="urn:foo"> <rpc:result xmlns:rpc="http://www.w3.org/2001/12/soap-rpc"/> <b:result xmlns:b="urn:b"/> </m:fooResult> as the soap node would know that rpc:result is the 'unnamed' return value and treat it accordingly to prevent the local name conflict. > > This can be achieved if a language binding uses namespaces >instead of underscores. > Possible solution - we can say that the struct can contain only >one edge whose local name is 'result'. > But not required if the FQN of result is fixed and can be identified by the processor and dealt with to prevent conflict. > > In effect, we'd be adding complexity in language bindins (in >most languages a parameter can be named 'result') and unnecessary >restrictions in the structs (going across all possible namespaces >which we shouldn't be able to affect) *only* because we want to >use an unsuitable language to describe SOAP RPC in the easy way. >I'd rather use the language in a slightly more complex way than >change SOAP here. > I don't think this adds any more restrictions on structs than are already present. How would a SOAP processor handle duplicate names in general when in different namespaces? It is not specific to result. Having a specific name for the result allows the soap processor to at least identify it as such and take action. > > A sketch of a possible solution for WSDL if we stick with the >fully qualified name rpc:result (for those who wonder): > > <message name="getStockQuoteResult"> > <part name="anything" element="tns:returnTypeElement"/> > </message> > > <binding> > <operation name="getStockQuote"> > ... > <output message="tns:getStockQuoteResult"> > <soap12:returnValuePart name="anything"/> > </output> > </operation> > </binding> > > And the returnValuePart would always be represented in the >resulting SOAP message as rpc:result, no matter it's original >name (tns:returnTypeElement). > My initial reaction to this was that I quite liked the idea. But, then thinking about it, I'm not sure it actually adds any value. If the name has to be mapped to rpc:result anyway, where would this mapping be done? It depends on where the processor has the WSDL available (at which level). Chances are it may apply the WSDL rules and then serialize the resulting graph. If this is the case then the name is transformed within the struct and the conflict again results where the struct is not supporting the multiple versions of result. This would force many processors to have to somehow hack in names to be substituted during serialization which gets messy or forces the processor to be written in a certain way that it cannot abstract the serialization completely away from the SOAP processing. It also means that the resulting message is exactly as described now in the draft (2002/04/10) spec and so the spec would not have to change. What is presented in WSDL (as above) is not really any worry to the SOAP spec, only what ends up on the wire. If I understand correctly you are saying to leave the spec as it is currently as far as the wire content? Sorry to be disagreeing all the time, but I quite like the way the struct response is currently in the draft spec. I seem to recall someone posting a while back to soapbuilders with a proposal to use an attribute on the response method <env:Body> <m:mymethodResponse env:hasreturn="true" > <out1>xxx</out1> <out2>yyy</out2> </ </ and, if it is true then the return value must be the first in the struct/array. This would work for both the array and struct case and the name would then not be significant in either case. I'm not proposing this as a great solution - I've just remembered it as I type - but at least it works for both array and struct and leaves no ambiguity in the message. Perhaps something along these lines ... ? Pete
Received on Tuesday, 16 April 2002 08:52:08 UTC