Re: [bt-spec] Re BTP Issue 103 (was issues 100, 101, 103 and 105)

[Mark Little <mark_little@hp.com>]

> I really don't understand why it makes a lot of difference whether the
> BEGIN, BEGUN exchanges are
>
> related-group
> begun
> decider-address
> transaction-identifier
> context
> superior-address
> superior-identifier
> superior-type
> qualifiers
>
> (using indentation rather than xml angles)
>
> against
>
> begun
> decider-address
> transaction-identifier
> superior-address
> superior-identifier
> superior-type
> qualifiers
>
> (unless you are arguing for some defaulting, which could be arranged
anyway
> on begun)

The difference is that context stands out as an enhancement to application
specific messages (it's the application's way of tying its participants into
the transaction) *except* in this one special case for BTP message BEGUN.
BEGIN/BEGUN isn't an application message set, it's part of the BT protocol.
If we can make a clear separation between which messages in the message set
are *only* used to drive the protocol engine and which are used (and seen)
by the application then this is a clarification that helps people to
understand what's going on. The *only* place CONTEXT appears in the BT
protocol message set is in BEGIN/BEGUN exchanges; the rest of the time (90%)
case it will appear in the application domain. What we are striving for is
to remove this cross over and end up with a clear separation of messages
into their respective domains: application and BT protocol.

> In the former case, the context is already there and ready to stuck on the
> application message, whereas in the latter it has to be constructed. It
> might be different if we had separate schemas for the different
> relationships, but when we discussed that it seemed a bad idea because
there
> were too many overlaps.
>
>
> Is it only the BEGUN&CONTEXT, BEGIN&CONTEXT groups you want to merge, or
to
> go back to containment for the other groups too ?

Only the former. Hence the instance that this is not a huge modification.

> In fact, are you wanting
> to change BEGIN as well, with optional superior-address and
> superior-identifier - BEGIN & CONTEXT is a lot more like putting CONTEXT
> with an application message (though it isn't quite the same)

It's like it, though you're right, it isn't exactly the same. However, it
does more clearly put CONTEXT within the application domain.

>
> another note at end:

> I don't see "proposed solution" text here, or a change-marked text.
Changes
> would need to state the new parameters and explanation of them for BEGIN
and
> BEGUN, and new text for CONTEXT to say where its values came from (iff the
> standard control Initiator:Factory relationship had been used). And in the
> xml.

OK. Text modifications to follow later today.

Mark.

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250