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

Re: [getf] Node MUST process? (was: [GETF] okay, here's an updateddraftwithHenrik's option B)

From: Christopher Ferris <chris.ferris@sun.com>
Date: Thu, 06 Jun 2002 09:34:27 -0400
Message-ID: <3CFF64E3.6020107@sun.com>
To: Jean-Jacques Moreau <moreau@crf.canon.fr>
CC: Henrik Frystyk Nielsen <henrikn@microsoft.com>, noah_mendelsohn@us.ibm.com, xml-dist-app@w3.org

+1 c'est bon

Jean-Jacques Moreau wrote:
> LOL !
> 
> ... but I like it! (I just now hope noone will disagree!)
> 
> Maybe a final minor tweak, mainly for consistency:
>     s/SOAP receiving node/SOAP receiver/
> 
> Jean-Jacques.
> 
> Christopher Ferris wrote:
> 
> 
>>Jean-Jacques,
>>
>>The SOAP processing model specifies[1] how a SOAP receiving node processes[2] a
>>                                                   ^^^^^^^^^
>>SOAP message. It applies to a single message only, in isolation from
>>any other SOAP message. The SOAP processing model itself does not[3]
>>maintain any state or perform any correlation or coordination between
>>messages[4], even, for example, when used in combination with a feature
>>which involves sending multiple SOAP messages in sequence, each subsequent
>>message depending on the response to the previous message. It is the
>>responsibility of each such features to define such combined[5]
>>processing.
>>
>>How 'bout the one minor tweak. Again, this constitutes my main concern
>>in that SOAP process rules have nothing to say about what a SOAP sending
>>node does with the message.
>>
>> > [2] I like "processing" better than "receiving" here. I think it's up to
>> > the MEP to specify what happens when a message is received. IMO, the
>> > processing model is concerned by the processing of messages only, not by
>> > their reception.
>>
>>I think I disagree. SOAP has nothing to say about processing a SOAP
>>message as it is being sent, or am I missing something fundamental?
>>
>>Cheers?
>>
>>Chris
>>Jean-Jacques Moreau wrote:
>>
>>>Close. How about the following minor tweaks:
>>>
>>>The SOAP processing model specifies[1] how a SOAP node processes[2] a
>>>SOAP message. It applies to a single message only, in isolation from any
>>>other SOAP message. The SOAP processing model itself does not[3]
>>>maintain any state or perform any correlation or coordination between
>>>messages[4], even, for example, when used in combination with a feature
>>>which involves sending multiple SOAP messages in sequence, each
>>>subsequent message depending on the response to the previous message. It
>>>is the responsibility of each such features to define such combined[5]
>>>processing.
>>>
>>>Jean-Jacques.
>>>
>>>[1] I don't remember whether there was any introductory context. In any
>>>case, I thought an extra introductory sentence was necessary.
>>>
>>
>> > [2] I like "processing" better than "receiving" here. I think it's up to
>> > the MEP to specify what happens when a message is received. IMO, the
>> > processing model is concerned by the processing of messages only, not by
>> > their reception.
>>
>>>[3] I think the active is more appropriate than the passive here.
>>>
>>>[4] "between messages" may not be necessary.
>>>
>>>[5] I am unuse of the adjective to use here. I think we need to say
>>>point out to features as being the place where you define such
>>>functionality; but maybe you will think this should go into the MEP
>>>section section?
>>>
>>>
>>>>So, with that, here is a slight tweak:
>>>>
>>>>    The SOAP processing model applies to a SOAP node
>>>>    receiving a single message only, in isolation
>>>>    from any other SOAP message. There is no state,
>>>>    correlation or coordination at the SOAP processing
>>>>    model level, even, for example if using a feature
>>>>    which involves sending multiple messages in
>>>>    sequence, each subsequent message depending on
>>>>    the response to the previous message.
>>>>
>>>>
>>>
>>>
> 
> 
Received on Thursday, 6 June 2002 09:37:39 GMT

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