Proposal for Shortcut Syntax for Simple Operations

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”? encodingStyleDefault=“xs:anyURI”?> <operation name=“xs:NCName” pattern=“xs:anyURI” encodingStyle=“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 .. not fully defined .. />* <outfault .. not fully defined .. />* </operation> </interface>

4. Problems with Status Quo • User has to remember pattern URIs • 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 • “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 the names chosen by the pattern authors for the messages is unacceptable • It would be better if error-prone redundancies were eliminated • 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 • Thus, value of message reference is implied by the direction • 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

7. Rules for Syntactic Shortcuts • 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) • 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”? encodingStyleDefault=“xs:anyURI”?> <operation name=“xs:NCName” encodingStyle=“xs:anyURI”?> <input body=“xs:QName”? headers=“list of xs:QName”?/> <output body=“xs:QName”? headers=“list of xs:QName”?/>? <fault details=“xs:QName”/>* </operation> </interface>

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

10. Bindings

11. Status Quo Should be “messageReference” <binding name=“xs:NCName” interface=“QName”?> ... interface-wide bindings ... <operation name=“xs:QName”> ... operation-wide bindings ... <input name=“xs:NCName”> ... input bindings ... </input>* <output name=“xs:NCName”> ... output bindings ... </output>* <infault .. not fully defined .. />* <outfault .. not fully defined .. />* </operation> </binding>

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