- From: Mountain, Highland M <highland.m.mountain@intel.com>
- Date: Tue, 22 Jan 2002 16:29:47 -0800
- 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 UTC