Re: Why aren't two input/output elements allowed to share the same messageReference value?

Okay.  It's an interesting scenario, but is achievable in other 
fashions (place an optional feature on the input, provide a choice 
content model for the output).  So I'm not convinced that the 
alternative exposure of functionality is worth the cost in complexity.

On Jan 26, 2004, at 5:48 PM, Yaron Goland wrote:

> Backwards/Forwards Compatibility - A service deploys that accepts an
> incoming message MIN. There is an optional extension for MIN that 
> specifies
> that the sender understands a new version of the service. MIN messages 
> that
> contain the optional extension we will call MIN*.
> If the service receives MIN then it returns MOUT.
> If the service receives MIN* then it returns NMOUT.
> NMOUT is a completely new message than MOUT.
> By supporting this message pattern it is possible for the service to 
> be both
> backwards (MIN) and forwards (MIN*) compatible all in one operation.
> There are, however, at least two problems with implementing this 
> scenario in
> WSDL 2.0:
> 	Element Collision - WSDL 2.0's output XML element has a message 
> attribute
> whose value is the QNAME of an Element definition. Since MOUT and 
> NMOUT are
> two different messages they don't have the same root element.
> 	Binding Collision - One can trivially imagine that MOUT and NMOUT 
> will have
> different binding options. For example, NMOUT may supports WSDL 
> functions
> that MOUT doesn't and visa versa.
> If we allowed multiple input/output elements to share the same
> messageReference value then we can easily, clearly and consistently 
> address
> these issues.
> 	Thanks,
> 		Yaron
>> -----Original Message-----
>> From: []On
>> Behalf Of Amelia A Lewis
>> Sent: Monday, January 26, 2004 12:16 PM
>> To: David Orchard
>> Cc:
>> Subject: Re: Why aren't two input/output elements allowed to share the
>> same messageReference value?
>> What value does permitting this have?  It is already
>> perfectly feasible
>> to define a message in such a way that you can have a choice content
>> model (inside a singly defined outer element, true).  If the message
>> that needs to have multiple different outer elements is the
>> first in a
>> pattern, then it follows that you have multiple operations, not
>> multiple possible content models for one operation (otherwise the
>> impact on dispatch mechanisms is likely to be quite severe).
>> I suppose
>> it might be valuable to allow a choice of message content for the
>> second and later message in a sequence, but why repeat the input or
>> output element?  It would seem to be more reasonable to revisit
>> (again!) the question of what the
>> attribute-pointing-at-the-content-model-for-this-message may contain.
>> Moreover, permitting multiples removes the ability to use the omitted
>> messageReference attribute shorthand (which is currently
>> permitted for
>> *all* the message exchange patterns defined in part two).  Note,
>> please, that I don't want to argue about the utility of that;
>> y'all can
>> argue with Sanjiva on that one.  I'm just pointing out that
>> so long as
>> cardinality of input/output elements inside an operation is directly
>> tied to their cardinality in the referenced Message Exchange Pattern,
>> then this form of shorthand is possible.
>> Amy!
>> On Jan 26, 2004, at 2:58 PM, David Orchard wrote:
>>> Why prevent message styles where a role could potentially
>> be filled by
>>> a
>>> choice of messages? Note that this is different than the multi MEPs
>>> that
>>> were just removed, those allowed for multiple responses not a single
>>> response which could be filled by one of a number of messages.
>>> Cheers,
>>> Dave

Received on Tuesday, 27 January 2004 14:21:59 UTC