Upload
raoul
View
30
Download
1
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
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
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
<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>
Proposal for Making “name” Optional
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 uniquen
ess etc.!!
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
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