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

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
- User has to know contents of pattern spec to know proper values
  for @messageReference (typically 'A', 'B' etc. right now). The
  value for @messageReference is *not* user settable, while the
  other attributes are - which I believe to be counter-intuitive.
- "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
- "infault" / "outfault" separation similarly redundant and error-prone

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 Friday, 31 October 2003 16:27:24 UTC