Proposal for Interface Extension Simplification

Slide image generated by PowerPoint
Sanjiva Weerawarana
September 21, 2003

Summary

Slide image generated by PowerPoint
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

Proposal for Making "name" Optional

Slide image generated by PowerPoint
<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>

Rules for Interface Extensions

Slide image generated by PowerPoint
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

Proposal for Operation Equivalence

Slide image generated by PowerPoint
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

Slide image generated by PowerPoint
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
Outline
  Notes