RE: New AFTF draft.

Herve and I have took an action item to respond to Chris' comments [2]
on the "SOAP 1.2 Attachment Feature" WD [3]. I think the intent was to
add the issue to the non-last call issues list [1] but I can't find it.
However, I felt it was better to get something started now rather than
wait. Herve (and others), please fill in as you see fit.

>"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.

You're right that there is no connection in any way to WSDL's term
"part" and also not to any term that MIME uses. DIME actually doesn't
use "part". From now on I will only use Danish terms ;)

I don't have a strong preference. A more hypertext related term would be
"document" but that has downsides too. I can't think of any term that
isn't already used in some manner that might be perceived as being
related.

> 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.

I would rather say that things like DIME provides a binding or a
representation of a compound SOAP structure. It is indeed not the intent
that a SOAP structure must be equated to the unit of a binding:

"Note: the compound SOAP structure model is independent of the
underlying protocol used for transmitting 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 transmitted
within the same unit of the underlying protocol. Note that in some
cases, the underlying protocol may also provide the functionality of the
encapsulation mechanism." 

> "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.

I agree. The very next paragraph states that 

"Secondary parts are often informally referred to as "attachments".
While the attachment relationship is expected to be commonly used, the
model makes no assumption about the nature of the semantic relationship
between the primary SOAP message part and secondary parts, or between
secondary parts."

The paragraph starting "Secondary parts can be used..." is meant as
examples, not formal definition. Might be good to add "For example," in
front.

> "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.

I agree that a binding must provide the list you mention--I think it is
very similar to the list stated in section 6. However, while this
constitutes requirements to a specific binding, I don't think it is a
processing model for the abstract feature. A specific binding may of
course provide a processing model of its own but that is somewhat out of
scope of this particular feature I would say.

> "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.

It seems to me that SOAP tries to do something very different from what
the SOAP attachment feature tries to do. SOAP specifically is designed
to provide an extensible and flexible processing model for the
components of the SOAP message. The attachment feature, however, does
not provide this at all--it merely provides a means for talking about
how compound structures can be organized and represented by a binding.

For example, if we believe that modeling attachments through generic
references, then it seems to follow that we cannot in general guarantee
that a recipient can (or even wants to) dereference these references.
Likewise, as we allow for the references to have arbitrary relationships
it seems to be out of scope of the attachment feature spec to dictate
what should be done with these references.

Hope this makes sense,

Henrik Frystyk Nielsen 
mailto:henrikn@microsoft.com 

[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0233.html
[3] http://www.w3.org/TR/2002/WD-soap12-af-20020814/

Received on Tuesday, 10 September 2002 00:30:48 UTC