ALTERNATIVE PROPOSAL: Short-cut syntax for in-out and in-only patterns

I would like to make the following alternative proposal. I believe it 
addresses Sanjiva's main issues.

The syntax for an in-out operation would be as follows:

      <interface name="xs:NCName"
                 extends="list of xs:QName"?
                 styleDefault="xs:anyURI"?>
         <operation name="xs:NCName"
                    pattern=".../in-out"
                    style="xs:anyURI"?>
            <A body="xs:QName"?
               headers="list of xs:QName"?/>
            <B body="xs:QName"?
               headers="list of xs:QName"?/>?
            <F details="xs:QName"/>*
         </operation>
      </interface>

Other patterns would be treated in a similar way.

Note: we might wish to define A, B, etc. in a different namespace, for 
example "wsdlp".

Note: this is not a fully-fledged proposal, which people are unlikely to 
have time to read before the f2f. I am happy to draft an enhanced 
proposal if the WG wishes so.


Comments on Sanjiva's proposal below. Basically, I am concerned 
Sanjiva's proposed syntax trades-off clarity for heuristics.

Jean-Jacques.


Sanjiva Weerawarana wrote:

> This is a follow-up email to the proposal I made at the last F2F
> to introduce some defaulting rules to make the syntax for 
> in-out and in-only patterned operations more syntactically 
> pleasing. 
> 
> Status quo syntax for operations:
> --------------------------------
>  
>     <interface name="xs:NCName" 
>                extends="list of xs:QName"? 
>                styleDefault="xs:anyURI"?> 
>        <operation name="xs:NCName" 
>                   pattern="xs:anyURI" 
>                   style="xs:anyURI"?> 
>           <input messageReference="xs:NCName" 
>                  body="xs:QName"? 
>                  headers="list of xs:QName"?/>* 
>           <output messageReference="xs:NCName" 
>                   body="xs:QName"? 
>                   headers="list of xs:QName"?/>* 
>           <infault messageReference="xs:NCName" details="xs:QName"/>* 
>           <outfault messageReference="xs:NCName" details="xs:QName"/>* 
>        </operation> 
>     </interface> 
> 
> 
> Problems with status quo:
> ------------------------
> 
> - User has to remember pattern URIs, even for simple operations

Srictly speaking, the user has to remember only the pattern URI's tail, 
i.e. in-only, in-out, out-only, etc; the rest 
(http://www.w3.org/@@@@/@@/wsdl/) is WSDL's standard prefix. Remembering 
the tail sounds simple enough to me.

> - User has to know contents of pattern spec to know proper values
>   for @messageReference (typically 'A', 'B' etc. right now).

Perhaps. However, again, 'A', 'B', etc. look to me like names the user 
is likely to be able to remember.

 >   The
>   value for @messageReference is *not* user settable, while the
>   other attributes are - which I believe to be counter-intuitive.

Yes. However I think we can address this in a different way (see 
proposal above).

> - "input" and "output" are redundant as the pattern defines the 
>   direction of the message - thus the indicated message reference
>   already has a set direction and the user cannot change it. Thus
>   indicating both message reference and input vs. output is an
>   an opportunity for errors

Agreed. I think we can address this in a different way as well (see 
proposal above).

> - "infault" / "outfault" separation similarly redundant and error-prone

Ibid.

> To me, requiring users to remember pattern URIs for the everyday
> patterns is unacceptable. Furthermore, requiring *users* to know
> the content of the patterns spec for those patterns (so that they
> can assign proper values for @messageReference) is even worse. W.r.t.
> the redundancies- I'd like to eliminate as many redundancies as
> possible. Finally, the motivation for the proposal is to keep the
> simple case simple, yet not harm the complex case in any way.
> 
> Proposal:
> --------
> 
> I proposed that we introduce a set of very simple rules to enable
> one to derive the message exchange pattern URI and message reference
> names for operations using the in-only and in-out patterns.
> 
> We observe that for the in-only MEP there is only one input message
> and no fault messages. Similarly, the in-out MEP has one input
> message, one output message and zero or more outfaults, all of 
> which are related to the single output message.
> 
> Proposed syntactic changes:
>     - Make interface/operation/@pattern optional
>     - Make interface/operation/(input|output)/@messageReference
>       optional
> 
> Now, introduce the following rules to compute these when they are 
> absent:
>     - There must be precisely one <input> element inside the 
>       operation- if not its an error as the user should have 
>       specified the MEP
>     - There must be precisely zero or one <output> element inside the
>       operation- if not its an error as the user should have 
>       specified the MEP
>     - There must not be any <infault> elements inside the operation-
>       if not its an error as the user should have specified the MEP
>     - If there is an <output> element, then @pattern="in-out" else
>       @pattern="in-only"
>     - Set value of the messageReference attribute for the <input>
>       element to 'A' (or if indicated it better be 'A')
>     - If there is an <output> element, set the value of its 
>       messageReference attribute to 'B' (or if indicated it better be 'B')
>     - If pattern is "in-only", then there must not be any <outfault>
>       elements or its an error
>     - If there are any <outfault> elements, set the value of its
>       messageReference attribute to 'B' (or if indicated it better be 'B')
> 
> The resulting syntax for in-only and in-out operations is:
>  
>     <interface name="xs:NCName" 
>                extends="list of xs:QName"? 
>                styleDefault="xs:anyURI"?> 
>        <operation name="xs:NCName" 
>                   style="xs:anyURI"?> 
>           <input body="xs:QName"? 
>                  headers="list of xs:QName"?/>
>           <output body="xs:QName"? 
>                   headers="list of xs:QName"?/>?
>           <outfault details="xs:QName"/>* 
>        </operation> 
>     </interface> 
> 
> A similar simplification is possible for <binding>s for in-only
> and in-out patterned operations (basically make the @messageReference
> attribute optional).
> 
> Conclusion:
> ----------
> 
> We believe that these proposed shortcuts are critical to support 
> what we believe to be easily the 80-20 usecase of WSDL; WSDLs 
> that have only in-only or in-out operations. The proposed 
> changes are minimal (make two attributes optional) and the
> proposed rules are very simple to implement even on small devices
> (or large mainframes). We believe that the resulting user-level
> simplification clearly justifies the adoption of this proposal.
> 
> Sanjiva.
> 
>

Received on Monday, 3 November 2003 04:47:03 UTC