Re: TBTF: Ed Note Section 5.1 - An attempt to clarify

Mountain, Highland M wrote:

>All,
>
>The statements below are my attempt to reconcile the ongoing conflict within
>the TBTF surrounding section Part 1, 5.1.  The statement preserves the
>modular layered approach while being more specific as to the responsibility
>and definition of features expressed as SOAP Headers.
>
>
>Current text:
>
>It is up to the communicating nodes to decide how best to express particular
>features; often when a binding-level implementation for a particular feature
>is available, utilizing it when appropriate will provide for optimized
>processing.
>
>Suggested change (which keeps the spirit of what we initially tried to state
>(Glen, Stuart and Henrik's position) but clarifies the balance of
>responsibility such that readers are not left with a vague notion of where
>SOAP Header features should be defined):
>
>It is up to the application developer to decide how best to express
>particular features. If a particular feature is not available at the
>transport binding-level, or will not be appropriate in the given end-to-end
>messaging scenario, it is up to the application developer to capture the
>requirement for features expressed in the envelope via WSDL or some other
>construct outside the transport binding specification.  The communicating
>nodes must then understand the representation and requirements of such
>features to facilitate interoperability.
>
Can we replace "it is up to" with "it is the responsibility of" ? I 
don't think we should mention WSDL. The text still sounds a little 
muddled to me, instead how about:

When a particular feature set is required, it is the responsibility of 
the application developer to choose a suitable combination of binding 
and in-the-envelope expressed features. Often when a particular feature 
is implemented in the binding, utilizing it in preference to an 
in-the-envelope representation will provide for optimised processing.

Marc.

>
>Are we getting closer to a compromise?
>
>Thanks,
>
>Highland
>
>....................Spec content and ed note of current WD
>
>The combination of the SOAP extensibility model and the SOAP binding
>framework provides some flexibility in the way that particular features can
>be expressed: they can be expressed entirely within the SOAP envelope (as
>blocks), outside the envelope (typically in a manner that is specific to the
>underlying protocol), or as a combination of such expressions. It is up to
>the communicating nodes to decide how best to express particular features;
>often when a binding-level implementation for a particular feature is
>available, utilizing it when appropriate will provide for optimized
>processing.
>
>
>
>Editorial note: HFN	20011201	
>Some discussion continues on how best to represent the balance of
>responsibility between binding specifications in particular, vs. other
>software at the SOAP node, when dealing with features that are represented
>entirely within the SOAP envelope. The paragraph above may need some
>additional work to clarify	
>
>
>Highland Mary Mountain
>
>Intel Corporation
>Distributed Systems Lab (DSL - CTG)
>(480) 552 - 3817
>
>highland.m.mountain@intel.com
>
>

Received on Wednesday, 23 January 2002 05:43:38 UTC