Wire Trace approach to MEP/Binding descriptions.

TBTF'ers,

I have attached an alternate description of the request/response MEP and
corresponding HTTP binding description. I created these to see how following
through on some ideas I first exposed to the TBTF in [1] (forwarded to a
public archive at [2]) would effect the MEP and Binding Specifications. I
did not circulate them at the time because we were trying to converge on a
direction, but I would now like to offer them for TBTF and wider
consideration as we move forward.

The approach here is to describe a message exchange pattern by describing
the sequences of events that can arise on the (virtual) wire during a
message exchange - wire traces. The attached MEP and HTTP descriptions were
produced directly from the material that we were using at the time [3,4] and
I have not kept them in sync with the TBTF material that went into the
recent working draft publications. At the time the conversion didn't take
very long. IMO the result makes both the MEP and the HTTP binding
descriptions more compact and complete... at the expense of using a process
algebraic notation for describing the state machine which may make the
presentation less accessible. 

I think that the state machine captured in the algebraic expressions
addresses the second issue that Eamon raise in [5] about the ability of the
FSMs described (now in the current WDs) to process responses that overlap in
time their corresponding request. I've included the manipulations that
produce the state machine below.

I'm not pushing this approach hard. I'd just ask the question of whether it
usefully improves the presentation of our binding related material. If so, I
would be happy to bring it up to date and work with the editors to include
it into our next WD.

Best regards

Stuart
PS: I'm also aware that we receieved several items of feedback on the TBTF
materials. I will catalog those in a separate message so that the TBTF begin
to respond to those (along with the several issues from the issues list
assigned to the TBTF).
--

Events:
	SOReq		Start-of-Request
	EOReq		End-of-Request
	SOResp	Start-of-Response
	EOResp	End-of-Response
	fail		Some abnormal termination.

Process:
srr-exchange = SOReq.(  EOReq.(SOResp.(EOResp | fail) | fail)
                      | SOResp.(   EOReq.(EOResp | fail)
                                 | EOResp.(EOReq | fail)
                                 | fail) )
                      | fail ).stop

Can be rearranged as:

srr-exchange = SOReq.S1
	S1 = EOReq.S2  | SOResp.S3 | (fail.stop)
	S2 = SOResp.S4 | (fail.stop)
	S3 = EOReq.S4  | EOResp.S5 | (fail.stop)
	S4 = EOResp.stop | (fail.stop)
	S5 = EOReq.stop  | (fail.stop)

Each line effectively repesents a state.

I'd have to check on my use of operator: parallel composition, choice and
sequence. Choice may traditionally be '+' rather than '|' as I've used here.

[1] http://lists.w3.org/Archives/Member/w3c-archive/2001Oct/0008.html
[2] http://lists.w3.org/Archives/Public/www-archive/2002Jan/0017.html
[3] http://www.w3.org/2000/xp/Group/1/10/11/2001-10-11-SRR-Transport_MEP
[4]
http://www.w3.org/2000/xp/Group/1/10/11/2001-10-11_Framework_HTTP_Binding
[5] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0041.html