Re: Resolving the ednote in part 1 section 5.1

Henrik,

Thanks for the review. I think your suggested edit does indeed
make it a bit clearer:) Thanks again.

Chris

noah_mendelsohn@us.ibm.com wrote:

> This looks fine to me, thanks! .  A couple of comments/suggestions:
> 
> * Editorial:  I think  "It is recommended that end-to-end features should 
> be expressed as SOAP header blocks so that they may avail themselves of 
> the SOAP processing rules" might be replaced by  "It is recommended that, 
> where practical, end-to-end features be expressed as SOAP header blocks, 
> so that SOAP's processing rules can be employed."  Not perfect, but a bit 
> closer I think.  The construction: "It is recommended that end-to-end 
> features should be expressed...so that they"  seemed a bit awkward to me.
> 
> * Did we make a final TBTF decision to leave the introduction of the term 
> "Feature" within chapter 5?  I know we didn't make a firm resolution to 
> move it out, and I think we all agreed not to significantly delay progress 
> to last call.  Still, it's not clear that moving it would be hard.  We've 
> agreed that in the formulation below "feature" becomes a term that has 
> significance well beyond the binding framework, suggesting that having it 
> introduced in the middle of a section on binding frameworks is 
> sub-optimal.
> 
> Thanks. 
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
> 
> 
> 
> 
> 
> "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
> Sent by: xml-dist-app-request@w3.org
> 02/13/2002 02:00 PM
> 
>  
>         To:     <xml-dist-app@w3.org>
>         cc: 
>         Subject:        Resolving the ednote in part 1 section 5.1
> 
> 
> 
> The following note looks more complicated than it is. The reason is that
> it tries to convey the discussion in the TBTF that led up to this mail.
> If you don't care about the discussion then you can jump directly to the
> PROPOSAL at the end.
> 
> DISCUSSION
> ----------
> 
> The ednote placed in section 5.1 of part 1 [0] has been the subject of
> ongoing debate in the TBTF for a long time. It states that:
> 
> "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"
> 
> And is in response to the paragraph just above which says:
> 
> "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."
> 
> On Feb 8, Chris Ferris posted a proposal [2] for resolving issue 178 [1]
> which is highly related. It proposes to add a note to the end of section
> 5.1 saying:
> 
> "Note: Certain features may require end-to-end as opposed to
> hop-to-hop processing semantics. While the binding framework
> provides for the possibility that such features may be expressed
> outside the SOAP envelope, it does not define a specific
> architecture for the processing or error handling of these externally
> expressed features by a SOAP intermediary. A binding specification
> that expresses such features external to the SOAP envelope should
> define its own processing rules to which a SOAP node
> is expected to conform (for example, describing what information
> must be passed along with the SOAP message as it leaves
> the intermediary). It is recommended that end-to-end
> features should be expressed as SOAP header blocks so that
> they may avail themselves of the SOAP processing rules [ref]."
> 
> During the discussion in the TBTF, it was argued that the existing
> paragraph (for which the ednote is targeted) and Chris's note describe
> very similar aspects but from slightly different viewpoints. The
> existing note describes it from the point of view of who makes
> decisions, whereas Chris's note describes it from the possible
> difference in scope of features expressed in the binding vs. features
> expressed in the SOAP envelope. Furthermore, it was argued that while
> the first part of the original note was useful, it doesn't seem to be
> within our scope to indicate who makes what decisions, and so we felt it
> was appropriate to delete the last sentence of the original note.
> 
> PROPOSAL
> --------
> 
> The TBTF therefore suggests that the way we discharge the ednote is by
> deleting the last sentence of the original paragraph in part 1, section
> 5.1 and add Chris's note. The result is:
> 
> "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.
> 
> Note: Certain features may require end-to-end as opposed to hop-to-hop
> processing semantics. While the binding framework provides for the
> possibility that such features may be expressed outside the SOAP
> envelope, it does not define a specific architecture for the processing
> or error handling of these externally expressed features by a SOAP
> intermediary. A binding specification that expresses such features
> external to the SOAP envelope should define its own processing rules to
> which a SOAP node is expected to conform (for example, describing what
> information must be passed along with the SOAP message as it leaves the
> intermediary). It is recommended that end-to-end features should be
> expressed as SOAP header blocks so that they may avail themselves of the
> SOAP processing rules [ref]."
> 
> Henrik Frystyk Nielsen
> mailto:henrikn@microsoft.com
> 
> [0] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#NA6A
> [1] http://www.w3.org/2000/xp/Group/xmlp-issues#x178
> [2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0168.html
> 
> 
> 
> 
>

Received on Friday, 15 February 2002 09:24:16 UTC