RE: New AFTF draft.

Henrik,

Thanks for the response. Some follow-up comments below.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

Henrik wrote on 09/10/2002 12:30:14 AM:

<snip/>
> >
> > 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 ;)

Innuit has 38 words (or something like that) meaning "snow", maybe 
it also has different words that all mean "part":)

A note that made this clear might be useful.

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

Well, there's 'resource' which fits in nicely with the Web architecture.

e.g.
        "Compound SOAP structure
          A compound SOAP structure consists of a primary SOAP message 
part
          and zero or more related resources."

I would even go as far as to add: "identified by a URI".

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

Yes, I think I agree with the note, but I fear that because it is
just a note, it diminishes its importance. Maybe if instead of a note,
it were a part of the normative prose that would make me feel better.

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

That would help.

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

Hmmm... How is it that what I suggest is specific to a particular binding?
I would have thought it rather generic and non-specific.

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

I don't think that is what I was suggesting at all. I was trying to say
that we must be very careful about articulating the responsibilities of
various aspects of the SOAP node. In particular, there is a responsibility
(IMO, based on the citations above) of the implementation of the SOAP 
binding 
that implements this feature to provide the SOAP node with the "access
to services of the underlying protocols". 

What is currently specified suggests (to me) that the *means by which
the secondary part is dereferenced* is left entirely up to the
application-level code, which doesn't seem right to me. To my mind,
this is the responsibility of the implementation of the SOAP binding
to provide this service. Otherwise, you end up with application code 
tightly coupled with the specific protocol (DIME, MIME, etc.) used
to transmit the compound SOAP message (yuch!)

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