Issue #33 closed : modularity

At the face-to-face in Cannes, the WG voted to accept the proposed resolution described below for issue #33.  No changes to the specs are necessary to close this issue.

Modularity at the Top

The SOAP 1.2 processing model, combined with the ability to add arbitrary extensions to the protocol via the header mechanism, allows spec writers and implementors to cleanly implement pieces of additional functionality in an extremely modular fashion.  While it remains the case that some "best practices" documentation with regard to designing SOAP 1.2 "modules" would be useful, the spec itself has been carefully designed to allow for the composition of an almost infinite set of extensions authored by the W3C or any other parties.

Modularity at the Bottom

The Binding Framework in section 5 of part 1 of the spec lays out an architecture for designing transport bindings which may provide for an arbitrary number of "binding features", which may be characterized as semantic extensions to the base SOAP protocol which are provided by the binding/transport.  Bindings may be authored for any existing or future underlying protocol, and the framework allows SOAP nodes to utilize arbitrary feaures of any such protocol.

It is the opinion of the TBTF that these factors provide for sufficient modularity in the design of SOAP 1.2 to satisfy the 
requirement, and that issue 33 should therefore be closed.


Received on Wednesday, 6 March 2002 00:23:07 UTC