6
Proposal for Interface Extension Simplification Sanjiva Weerawarana September 21, 2003

Proposal for Interface Extension Simplification

  • 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

Page 1: Proposal for Interface Extension Simplification

Proposal for Interface Extension Simplification

Sanjiva Weerawarana

September 21, 2003

Page 2: Proposal for Interface Extension Simplification

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

Page 3: Proposal for Interface Extension Simplification

<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

Page 4: Proposal for Interface Extension Simplification

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

Page 5: Proposal for Interface Extension Simplification

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

Page 6: Proposal for Interface Extension Simplification

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