1 / 12

Proposal for Shortcut Syntax for Simple Operations

Proposal for Shortcut Syntax for Simple Operations. Sanjiva Weerawarana September 21, 2003. Operations. Status Quo. <interface name=“xs:NCName” extends=“list of xs:QName”? encodingStyleDefault=“xs:anyURI”?> <operation name=“xs:NCName”

chelsi
Download Presentation

Proposal for Shortcut Syntax for Simple Operations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related