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

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: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Amelia A Lewis
> Sent: Monday, January 26, 2004 12:16 PM
> To: David Orchard
> Cc: www-ws-desc@w3.org
> 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 Monday, 26 January 2004 17:48:47 UTC