Re: proposal for shortcutting <operation> syntax for simple operation patterns

+1. I agree with Amy, I would much prefer to make @messageRef optional
rather than @pattern. Making @pattern optional would not only make WSDL 
incoherent, but also create interop issues.

This being said, I agree with (most of) Sanjiva's original motivations.

Jean-Jacques.

Amelia A. Lewis wrote:

> I've extracted some points from the presentation, and present
> responses here.
> 
> On Mon, 22 Sep 2003 12:41:35 +0600 Sanjiva Weerawarana
> <sanjiva@watson.ibm.com> wrote:
> 
> 
>> Rationale Requiring users to remember pattern URIs for the commonly
>> used patterns is unacceptable
> 
> 
> No.  It is necessary.  It is not burdensome.  It is much more 
> straightforward than interpreting sequences of input/output.
> 
> 
>> Requiring users to remember the names chosen by the pattern authors
>> for the messages is unacceptable
> 
> 
> Not really.  Maybe in the case of the most common patterns, it is.
> But that supports making @messageReference optional for patterns
> containing only a single message in a given direction, not
> optionality of @pattern.
> 
> 
>> It would be better if error-prone redundancies were eliminated
> 
> 
> Agreed.  This justifies making messageReference optional for all 
> patterns in which there is only a single message in a given
> direction. It does not justify optionality of @pattern.
> 
> 
>> Keep the simple case simple
> 
> 
> Agreed.  Keep all cases consistent; do not make special cases that
> will make it harder to define additional patterns.
> 
> 
>> Rules for shortcuts Make (input|output)/@messageReference optional
>> and say the direction implies the reference because only one in
>> each direction
> 
> 
> Make this a general rule for all patterns.  If a pattern contains
> only one message in a given direction, then the @messageReference for
> that message is optional.
> 
> 
>> Say order of input/output significant (as today) Make @pattern
>> optional and say its value is computed based on order of 
>> input/output and whether both or only one is present
> 
> 
> No, no, no.  Keep the URI to disambiguate, leave order of operations 
> insignificant.
> 
> The problem with making this shortcut for this particular set of 
> patterns is that it privileges them so extremely that no other
> patterns are reasonably interoperable.  If the rule is: "look at the
> @pattern", it's clear.  This proposal says: "look at @pattern, and if
> it does not exist, then look at the sequence of messages and choose
> from a limited set".  In implementation, it is *guaranteed* that some
> folks will entirely ignore @pattern, and use *only* sequence, meaning
> that it will not be possible to define additional patterns that have
> different semantics from those that we provide shortcuts for.
> 
> Under those circumstances, I would argue, we should throw out all the
>  existing patterns work (as well as attempts to support any
> networking paradigm other than the strongly client/server).  I am
> *very* strongly opposed to this.
> 
> Note that the one thing in the proposal that I am opposed to is
> making the @pattern attribute optional.  I agree, in principle or in
> whole, with all of Sanjiva's points otherwise.
> 
> I'll reiterate: I *strongly* oppose the notion of making @pattern 
> optional.  I agree with all the rest of Sanjiva's presentation, apart
>  from the recommendation, based on making @pattern optional, that
> certain privileged patterns be recognizable from sequence.  I feel
> that providing a more complex algorithm for recognizing the pattern
> to which an operation conforms is not a good solution, but I like the
> syntactic shortcuts (optionality of @messageReference in both
> interface and binding, if the pattern has only one message in a given
> direction) otherwise.
> 
> Amy!

Received on Tuesday, 23 September 2003 03:50:59 UTC