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