1. Proposal for Shortcut Syntax for Simple Operations Sanjiva Weerawarana September 21, 2003

2. Operations

3. Status Quo <interface name=xs:NCName extends=list of xs:QName? extends=list of xs:QName? encodingStyleDefault=xs:anyURI?> encodingStyleDefault=xs:anyURI?> <operation name=xs:NCName <operation name=xs:NCName pattern=xs:anyURI pattern=xs:anyURI encodingStyle=xs:anyURI?> encodingStyle=xs:anyURI?> <input messageReference=xs:NCName <input messageReference=xs:NCName body=xs:QName? body=xs:QName? headers=list of xs:QName?/>* headers=list of xs:QName?/>* <output messageReference=xs:NCName <output messageReference=xs:NCName body=xs:QName? body=xs:QName? headers=list of xs:QName?/>* headers=list of xs:QName?/>* * * </interface>

4. Problems with Status Quo User has to remember pattern URIs User has to remember pattern URIs User has to know contents of pattern spec to know proper values for @messageReference User has to know contents of pattern spec to know proper values for @messageReference input and output are redundant as the pattern defines the direction of the message; the user cannot change it and hence its an opportunity for errors input and output are redundant as the pattern defines the direction of the message; the user cannot change it and hence its an opportunity for errors infault / outfault separation similarly redundant and error-prone infault / outfault separation similarly redundant and error-prone

5. Rationale for Proposal Requiring users to remember pattern URIs for the commonly used patterns is unacceptable Requiring users to remember pattern URIs for the commonly used patterns is unacceptable Requiring users to remember the names chosen by the pattern authors for the messages is unacceptable Requiring users to remember the names chosen by the pattern authors for the messages is unacceptable It would be better if error-prone redundancies were eliminated It would be better if error-prone redundancies were eliminated Keep the simple case simple Keep the simple case simple

6. Syntactic Shortcuts for Supported Patterns For In-only and In-Out patterns there is at most one message in each direction For In-only and In-Out patterns there is at most one message in each direction Thus, value of message reference is implied by the direction Thus, value of message reference is implied by the direction There may be >= 0 fault messages for In- Out There may be >= 0 fault messages for In- Out Since only one set of faults, value of message reference is unnecessary from the client point of view Since only one set of faults, value of message reference is unnecessary from the client point of view

7. Rules for Syntactic Shortcuts Make (input|output)/@messageReference optional and say the direction implies the reference because only one in each direction Make (input|output)/@messageReference optional and say the direction implies the reference because only one in each direction Say order of input/output significant (as today) 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 Make @pattern optional and say its value is computed based on order of input/output and whether both or only one is present

8. Proposal for Simplified In-only and In-Out Patterned Interactions <interface name=xs:NCName extends=list of xs:QName? extends=list of xs:QName? encodingStyleDefault=xs:anyURI?> encodingStyleDefault=xs:anyURI?> <operation name=xs:NCName <operation name=xs:NCName encodingStyle=xs:anyURI?> encodingStyle=xs:anyURI?> <input body=xs:QName? <input body=xs:QName? headers=list of xs:QName?/> headers=list of xs:QName?/> <output body=xs:QName? <output body=xs:QName? headers=list of xs:QName?/>? headers=list of xs:QName?/>? * * </interface>

9. Simplified Operations Pros & Cons User familiarity based on perceived and real similarity to WSDL 1.1 syntax User familiarity based on perceived and real similarity to WSDL 1.1 syntax No redundancy No redundancy This will be defined as a syntactic shortcut ONLY – not a new or special component This will be defined as a syntactic shortcut ONLY – not a new or special component ??

10. Bindings

11. Status Quo <binding name=xs:NCName interface=QName?> interface=QName?>... interface-wide bindings...... interface-wide bindings...... operation-wide bindings...... operation-wide bindings...... input bindings...... input bindings... * *... output bindings...... output bindings... * * </binding> Should be messageReference

12. Shortcuts Once interfaces have shortcuts then those naturally apply in bindings Once interfaces have shortcuts then those naturally apply in bindings Make (input,output)/@messageReference optional Make (input,output)/@messageReference optional