W3C home > Mailing lists > Public > www-ws-desc@w3.org > January 2004

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

From: Amelia A Lewis <alewis@tibco.com>
Date: Mon, 26 Jan 2004 15:16:12 -0500
To: David Orchard <dorchard@bea.com>
Cc: www-ws-desc@w3.org
Message-id: <7C9B1150-503C-11D8-9D84-0050E416A465@tibco.com>

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 15:16:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:28 GMT