RE: [bt-spec] BTP Issue 79 : Normalising the message set

[Peter Furniss <peter.furniss@choreology.com>]

Tony has pointed out to me that CONFIRM_ONE_PHASE should be in the outcome column of course.  It's really the outcome relation equivalent of REQUEST_CONFIRM. 

 

He also questioned what to do with REQUEST_STATUS and STATUS. These are not strictly part of the outcome or of the control relationship - anything can send REQUEST_STATUS, not just the immediate superior or the terminator. The question is where do they send it (posit an actor that plays superior, inferior, decider roles, but with different addresses (odd perhaps, but possible at the moment) - to which address(es) can you send REQUEST_STATUS or CHECK_STATUS ?.

 

Options would seem to be:

  a)    there are two message pairs, one used on address-as-inferior, one on address-as-decider

  b)    there is one message pair, used on either

  c)    we should not allow different addresses (and identifiers). (this would be an answer to a different question of course)

 

no doubt d) and e) can be invented - oh yes:

d) one message pair, used on any relationship, including the address-as-superior

 

I incline to b).

 

Peter

 

 -----Original Message-----
From: Peter Furniss [mailto:peter.furniss@choreology.com]
Sent: 15 December 2001 01:57
To: bt-spec@lists.oasis-open.org
Subject: RE: [bt-spec] BTP Issue 79 : Normalising the message set

This issue was discussed at the Liberty Corner ftf this morning.

 

The group concluded that it was a good idea, but that the messages should be given distinct names for the different uses on different relationships, rather than the qualifier.message style originally suggested. A set of name correspondences was drafted during the meeting (but not thrashed out in detail), as attached. This has been posted to the issues list as "outline solution".

 

(needs completing with a decision on the number of xml sub-schemas)

 

 

Peter