W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2002

Re: New AFTF draft.

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>
Message-ID: <OFB604AF7C.2F4FB83E-ON85256C07.003D7C17@rchland.ibm.com>


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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:10 GMT