Re: Resolving the ednote in part 1 section 5.1

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 Thursday, 14 February 2002 14:08:03 UTC