bt-spec message

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

From: BTP issues maintainer <peter.furniss@choreology.com>
To: bt-spec@lists.oasis-open.org
Date: Fri, 30 Nov 2001 18:43 +0000

This issue has been added to the BTP issue list

BTP Issue 79 : Normalising the message set

Submitter: Choreology
Category: technical
Description:
The BTP abstract message set should be split into subsets, each applicable to one of the "relationships" in BTP. The division should be reflected in the XML.

BTP Draft 0.9 covers the two "relationships" (control, outcome are names for these suggested in issue 62), but has a single set of messages. Some messages are used in only one relationship (REQUEST_CONFIRM in control, ENROL, CONFIRM in outcome), but some are used in both (PREPARE, CANCEL). The ones used in both tend to have some parameters used only in one case, some only in another.

Splitting the message set will not cause any difference in functionality - the same semantics can be exchanged between the various roles. It will simplify the abstract message specification, and the xml schema, and in turn should make implementation simpler (especially for implemenations that choose to support only the Superior:Inferior relationship and use an internal API for transaction control by the application. ) It should also make the conformance discussion and specification easier.

For XML, the names can easily be qualified by namespace, and it seems it will be simplest to invent something similar for the abstract messages - thus PREPARE would become CONTROL.PREPARE and OUTCOME.PREPARE.

There should also be a separate basic group, which would include things like FAULT and CONTEXT that are used in both relationships.

Possibly the Initiator:Factory relationship (using BEGIN, BEGUN) should have its own group (Factory)
Note: The choice of a single message set was made on the principle of
conservatism - in adding the coordinator and cohesion control messages [omitted from 0.6, which had not caught up with tc decisions], we were considered making two disjoint message sets, but concluded this would appear as to great a change.

To comment on this issue, please follow-up to this announcement on the bt-spec@lists.oasis-open.org (replying to this message should automatically send your message to that list).

The current draft, with line numbers is available in pdf format and word format.

To add a new issue, please email to Peter Furniss peter.furniss@choreology.com. It helps if you propose a category (technical, minor technical, editorial, minor editorial).