- From: Christopher Ferris <chris.ferris@sun.com>
- Date: Fri, 15 Feb 2002 09:29:29 -0500
- To: Christopher Ferris <chris.ferris@sun.com>
- CC: noah_mendelsohn@us.ibm.com, henrikn@microsoft.com, xml-dist-app@w3.org
Oops! I meant "Noah, thanks..." I was reading the "To:" line and not the "From:". Need more coffee:) Thanks Noah, (and you too Henrik for taking the AI to merge the changes) Cheers, Chris Christopher Ferris wrote: > 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 10:41:12 UTC