1 / 6

Proposal for Interface Extension Simplification

Proposal for Interface Extension Simplification. Sanjiva Weerawarana September 21, 2003. Summary. Motivation Current extension rules are complicated Requires a best-practice of putting each interface in its own namespace, for example

raoul
Télécharger la présentation

Proposal for Interface Extension Simplification

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 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

More Related