Re: [Fwd: Re: AFTF: new draft (resent)]

I have returned from vacation and reviewed the draft at [1].  Mostly, I
like it a lot, but I do have a few comments and concerns.  The most
significant, and one about which I feel strongly, relates to the section on
Representing Compound SOAP Structures, which seems to imply that every
implementation of the feature requires creation of an encapsulation
mechanism.   Specifically, it says:

"A representation of a compound SOAP structure MUST describe the following
three parts:

An encapsulation mechanism for the primary SOAP message part and for each
secondary part. The encapsulation mechanism MAY but need not be the same
for all parts."

I disagree.  Features are implemented by bindings.  There should be nothing
in this feature that should require the creation of an encapsulation
mechanism at all!  As correctly noted later in the document, it is OK for
the several parts to each be sent separately (e.g. with separate GETs).
Creating an encapsulation is just one of the strategies that can be used to
implement this feature, and it is not in all cases preferred.  I would not
call it out at all, except as an example of a likely strategy.  Instead, I
would replace the entire Representing Compound structs section with
something along the lines of:

<proposed>
Requirements on bindings implementing the SOAP Attachments Feature
-------------------------------------------------------------------

The compound SOAP structure model is abstract in the sense that it does not
define an actual means by which compound structures are represented or
transmitted by a SOAP binding.  This section describes the requirements on
any binding that uses this feature to transmit SOAP compound structures;
the definition of any particular representation or binding is outside the
scope of this specification.

A binding that supports the transmission of compound compound SOAP
structures MUST provide the following:

* A means by which the primary and secondary parts are made available to
the receiving party.  Typically, this is achieved by transmitting all of
the parts from the sender to the receiver, using binding-specified means.
One option for achieving such transmission is to use an encapsulation
mechanism (e.g. DIME or MIME) to prepare a single message containing all of
the parts, and to then transmit the encapsulation.

* A mechanism by which each part can be identified using a URI reference.
While the reference MUST be in the form of a URI, the mechanism by which
the URI is represented MAY but need not be the same for all parts.

NOTE:  The compound SOAP structure model is independent of the underlying
protocol used for exchanging the primary SOAP message part and any of the
secondary parts. That is, there is no requirement that all parts of a
compound SOAP structure representation be exchanged within the same unit of
the underlying protocol. Note that in some cases, an encapsulation
mechanism may also provide the functionality of the underlying protocol but
this is not a requirement.

[..deleted reference to representations and relationship to MEPs.  It's not
appropriate here.  The discussion in section 5 covers it.]

As examples of possible representations that a binding might implement, a
compound SOAP structure consisting of a primary SOAP message part
containing an insurance claim for a damaged car and a secondary part
containing a JPEG image of the car, can be represented in several ways
including but not limited to the following:

[... as before, perhaps with minor tweaking...]


</proposed>


Other less significant suggestions
----------------------------------

Section 1.0:
<original>
The purpose of this specification is not to define an actual representation
of SOAP attachments but rather to define an abstract SOAP 1.2 feature which
can be used as the basis for defining an appropriate representation.
</original>
<proposed>
The purpose of this specification is not to define an actual representation
of SOAP attachments but rather to define an abstract SOAP 1.2 feature which
can be used as the basis for defining SOAP bindings that support the
transmission of messages with attachments.  The feature describes
characteristics common to all such implementations.
</proposed>

Section 4.0:
<original>
the model makes no assumption about the nature of the relationship between
the primary SOAP message part and secondary parts
</original>
<proposed>
the model makes no assumption about the nature of the semantic relationship
between the primary SOAP message part and secondary parts
</proposed>
(it surely says a lot about the structural relationship, the means by which
URIs are used for reference, etc.)

Section 4.0:
<original>
It is important to note that the compound SOAP structure model does not
modify or supersede the message concept defined by SOAP
</original>
<proposed>
It is important to note that the compound SOAP structure model does not
modify or supersede the message envelope concept defined by SOAP
</proposed>
(it does indeed augment the notion of a message, it does not change the
notion of an envelope, I think.)

I hope these comments are helpful.  Thank you.

[1] http://www.w3.org/2000/xp/Group/2/07/SOAP-AF/aftf-soap-af.html

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Wednesday, 24 July 2002 13:23:34 UTC