Re: TBTF: DRAFT: revisions to MEP descriptions to address overlapping request response.

Looks good, a couple of editorial nits:

7.4.1.2 in table, statename should be requesting not waiting.
7.4.2.1 in table, statename should be init not receiving.
7.4.2.3 in table, statename should be receiving+sending not responding, 
same for table caption.

Regards,
Marc.

Williams, Stuart wrote:

> I've posted the following (with its attachments) to the W3C public archive
> [1]. Those that are interested will find the attachments there.
> 
> Regards 
> 
> Stuart
> 
> [1] http://lists.w3.org/Archives/Public/www-archive/2002Apr/0041.html
> --
> 
> Folks,
> 
> At the last TBTF telcon I took the action to see what it would take to
> change the request response MEP description so that it could accomodate
> temporal overlap between SOAP request and SOAP response. The changes are in
> sections 6 and 7 of the attached modified version of part 2 (just those
> sections).
> 
> The requesting and responding statemachines remain structurally similar to
> each other and have a simmilar appearance to the previous version. However,
> the starting state is more clearly marked as are the actions to 'get things
> moving'. The changes in section 6 should give a good feel for the
> difference. Only the final state (before success or fail) now waits for
> transmissions and/or receptions to complete, all other transitions are
> driven by the the availability of messages to send or the start of messages
> being received (or the failure of the underlying protocol or a local abort
> for whatever reason - actually the latter could be a property set in the
> MEC, but that is mostly editorial).
> 
> One noticable change is that I split context:CurrentMessage into an
> InboundMessage and an OutBoundMessage because of the potential for overlap.
> 
> Most of the 'dense' material in the HTTP binding tables (section 7) is
> unchanged, although some tables have changed position. The amendments to the
> binding description were pretty straight forward.
> 
> So... the quick way to review this is to consider section 6. If that makes
> sense to you, section 7 should not contain any surprises. (There is a chance
> I have done this in too much haste... so look out for errors as well).
> 
> This is up for discussion on the TBTF call on Friday.
> 
> Best regards
> 
> Stuart Williams
> 
> 


-- 
Marc Hadley <marc.hadley@sun.com>
XML Technology Centre, Sun Microsystems.

Received on Thursday, 18 April 2002 07:20:30 UTC