proposal for interface extension simplification n.
Skip this Video
Loading SlideShow in 5 Seconds..
Proposal for Interface Extension Simplification PowerPoint Presentation
Download Presentation
Proposal for Interface Extension Simplification

Proposal for Interface Extension Simplification

92 Vues Download Presentation
Télécharger la présentation

Proposal for Interface Extension Simplification

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Proposal for Interface Extension Simplification Sanjiva Weerawarana September 21, 2003

  2. Summary • Motivation • Current extension rules are complicated • Requires a best-practice of putting each interface in its own namespace, for example • Operation names do not show up on the wire and implies incorrect mental model • Requires (in effect) two QNames to identify an operation from a binding • Proposal • Make interface/operation/@name optional • Only necessary if one wants to enable per-operation bindings • Define operation equivalence structurally

  3. Proposal for Making “name” Optional <interface name=“xs:NCName” extends=“list of xs:QName”? encodingStyleDefault=“xs:anyURI”?> <operation pattern=“xs:anyURI” name=“xs:NCName”? encodingStyle=“xs:anyURI”?> <input messageReference=“xs:NCName” body=“xs:QName”? headers=“list of xs:QName”?/>* <ouput ... Similarly .../>* <fault ... TBD .../>* </operation> </interface>

  4. Rules for Interface Extensions • An interface MAY extend one or more other interfaces • The set of operations of an interface consists of those defined within that interface as well as those from all the extended interfaces • Note that the operations of an interface are a set: i.e., there are no duplicates; they are automatically eliminated when forming the set • Need definition for operation equivalence to make that work Nothing about QName uniqueness etc.!!

  5. Proposal for Operation Equivalence • Two Operations o1 & o2 are equivalent iff • They have the same pattern • Every corresponding message reference points to the same body and header element QNames • Every corresponding fault reference points to the same detail element QName • If indicated, values of @encodingStyle must be the same

  6. Impact • Instead of complications on how names must be unique and how interfaces should be in different TNSs (best practice), we just have to say that the set of all operations in an interface must be “different”, where different is based on definition of equivalence • I.e., no more names for operations for the purposes of extensions. They are there only to make it possible to do operation-specific bindings. • No more two QNames to identify an operation: A binding refers to an operation by the TNS of the interface and the NCName of the operation (like the old way) • NCName must be unique within the interface