W3C home > Mailing lists > Public > www-archive@w3.org > January 2002

TBTF: Ed Note Section 5.1 - An attempt to clarify

From: Mountain, Highland M <highland.m.mountain@intel.com>
Date: Tue, 22 Jan 2002 16:29:47 -0800
Message-ID: <ED492E16A0B8D311AC490090276D20841709BC8D@FMSMSX31>
To: "Christopher Ferris (E-mail)" <chris.ferris@sun.com>, "David Fallside (E-mail)" <fallside@us.ibm.com>, "Glen Daniels (E-mail)"<gdaniels@macromedia.com>, "Henrik Nielsen (E-mail)"<henrikn@microsoft.com>, "Hugo Haas (E-mail)" <hugo@w3.org>, "Marc. Hadley (E-mail)" <marc.hadley@sun.com>, "Mark A. Jones (E-mail) (E-mail)" <jones@research.att.com>, "Noah Mendelsohn (E-mail)" <Noah_Mendelsohn@lotus.com>, "Oisin Ohurley (E-mail)" <ohurley@iona.com>, "Stuart' 'Williams (E-mail)"<skw@hplb.hpl.hp.com>, "Yves Lafon (E-mail)" <ylafon@w3.org>
Cc: "'www-archive@w3.org'" <www-archive@w3.org>
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.


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 Tuesday, 22 January 2002 19:29:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:17:16 GMT