- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Wed, 31 Jul 2002 23:06:07 -0400
- To: "xml-dist-app" <xml-dist-app@w3.org>
AFTFers,
Some comments.
"Compound SOAP structure
A compound SOAP structure consists of a primary SOAP message part
and zero or
more related secondary parts."
I'm a little concerned that the term 'part' used in this spec will be
confused with the term
'part' as used in WSDL. It isn't clear to me that a 'part' in WSDL would
equate to a 'part'
as described in this spec.
The term 'part' as used in this context equates to MIME or DIME message
'part', which is certainly
one way to look at this, but IMO, not the only way to view it.
I'm also a little concerned with the use of the term 'compound SOAP
structure'. The serialization
of a SOAP message that contains references external to the SOAP envelope
may be as a compound
structure, but that again is just one way of achieving the objective of
making the referents available
to the receiving node(s). I look at the serialization of a SOAP message
and its referents using MIME
or DIME as an optimization that should be (nearly) invisible to both the
sending and receiving application,
not as its inherent structure.
"4. Compound SOAP Structure Model
A compound SOAP structure consists of a primary SOAP message part and
zero or more related secondary
parts that are distinct from the primary SOAP message but related to it
in some manner.
Secondary parts can be used to contain data that naturally represents a
resource in its own right or which is
cumbersome to represent within the primary SOAP message part. The
latter can be due to the size, type, or
format of the data--a secondary part may be an audio clip, an image, or
a very large view of a database, for
example."
Again, I look at the problem a little differently. A SOAP message may
contain references to resources that are external to the
SOAP envelope itself. The references themselves define the semantics of
the relationship between the SOAP message
and the referent resource. It is outside the scope of this specification
to attribute specific semantic relationship between
the SOAP message and its constituent parts (SOAP header blocks and the
contents of the SOAP body) and the
resources to which these may refer.
"It is important to note that the compound SOAP structure model does not
modify or supersede the message envelope
concept defined by SOAP. Nor does it define a processing model for any of
the parts of a compound SOAP structure
including the primary SOAP message part. The processing model for the
primary SOAP message part is defined by
SOAP. The application-defined semantics of the SOAP message provides the
processing context for the secondary
part(s)."
Actually, I believe that there *is* a processing model and that this
specification SHOULD articulate that processing
in the abstract (not in terms of specific bindings to a particular
technology such as MIME or DIME). To an extent,
this is discussed in section 6, but it is not characterized in the manner
that I believe it should be.
I believe that the processing model should be as follows:
- a sending SOAP node implementing this feature must serialize the
referents of any references in accordance
with the chosen "packaging" technology.
- a receiving SOAP node implementing this feature must provide
necessary functionality that enables any resources
referenced within the SOAP message to be resolved (dereferenced,
whatever term of art is chosen to mean
make the bytes of the representation(s) of the identified resource is
made available to the application).
I believe that that is the essence of this feature in a nutshell.
"The compound SOAP structure model does not require that a SOAP receiver
process, dereference, or otherwise
verify any secondary parts of a compound SOAP structure. It is up to the
SOAP receiver to determine, based on
the processing context provided by the primary SOAP message part, which
operations must be performed (if any)
on the secondary part(s)."
This paragraph troubles me deeply. I think that I understand the
motivation behind the text, but
I think it misses the point, at least from my perspective.
See the second bullet above regarding what I perceive are the receiving
SOAP node's responsibilities. I think
that we need to be careful in the language that we choose.
From SOAP1.2 part 1:
"SOAP node
The embodiment of the processing logic necessary to transmit,
receive, process and/or relay a SOAP
message, according to the set of conventions defined by this
recommendation. A SOAP node is responsible
for enforcing the rules that govern the exchange of SOAP messages
(see 2. SOAP Processing Model). It
accesses the services provided by the underlying protocols through
one or more SOAP bindings."
I think that we need to be very careful about articulating the
responsibilities of a SOAP node with respect to
any features that are defined. According to the definition above, a SOAP
node's responsibilities include 'processing'
which I believe we now mean to include the application-level processing .
From SOAP 1.2 part 1 section 2.6:
"4. Process all header blocks targeted at the node and, in the case of an
ultimate SOAP receiver, the SOAP
body. A SOAP node MUST process all SOAP header blocks targeted at it. A
SOAP node MAY choose
to ignore the application level processing specified by non-mandatory SOAP
header blocks targeted at it."
I believe that what the wording:
"The compound SOAP structure model does not require that a SOAP
receiver process,
dereference, or otherwise..."
is intended to mean that, just as the SOAP spec says nothing about what a
receiving SOAP node
does with the contents of a SOAP header block or the SOAP body, this
feature imposes no requirement
that the representations of the resources actually *be* processed,
dereferenced or otherwise validated, etc.
However, it DOES have a responsibility to provide for the means by which
the references can be resolved in the
event that the application-level processing determines that a particular
reference be resolved.
Bottom line for me is that we should define this feature in terms of SOAP,
not in terms of the
anticipated technology that might implement the feature.
Cheers,
Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624
"w3.ruellan@lapos
te.net" To: "xml-dist-app" <xml-dist-app@w3.org>
<w3.ruellan cc:
Sent by: Subject: New AFTF draft.
xml-dist-app-requ
est@w3.org
07/30/2002 09:26
PM
Dear all,
An updated version of the Abstract Feature document can be
found at:
http://www.w3.org/2000/xp/Group/2/07/SOAP-AF/aftf-soap-af.html.
Hervé.
Accédez au courrier électronique de La Poste : www.laposte.net ; 3615
LAPOSTENET (0,13 €/mn) ; tél : 08 92 68 13 50 (0,34€/mn)"
Received on Wednesday, 31 July 2002 23:07:39 UTC