Re: New AFTF draft.

Chris, Henrik,

Christopher B Ferris wrote:
>>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 have no strong preference one way or another. As I see it, we have 
three possibilities:

1 - Keep spec as is.
2 - Add a note making clear that the term "part" as used in the spec has 
no relation with the WSDL's term or the MIME's term.
3 - Change 'part' to 'resource'. This implies a revision of the whole 
spec with some editorial issues to solve:
     - Do we still have a 'Primary SOAP message part' or do we want to 
change its name to 'Primary SOAP message' ?
     - There is currently a sentence (in 3. Terminology) that reads: "A 
secondary part is a resource...".
     - ...


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

I think we can make this note not a note (does it make sense?), that is, 
just remove the "Note:" at the beginning of the paragraph.

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

+1.

>>>"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 think that these points are captured, without as much precision, in 
the sentence (from 6. Implementation):
"A means by which the primary and secondary parts are made available to 
the receiving party."

We could expand this sentence to be more specific. However this should 
be carefuly crafted not to rule out the possibility of just sending the 
SOAP message containing external references to the other parts which are 
retrieved using a classic HTTP GET.

> 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!)

 From my point of view, the spec is clear about this. However I'm ready 
to add some text for making it clearer, but I'm not sure what to add and 
where.

Regards,

Hervé

Received on Tuesday, 10 September 2002 12:03:47 UTC