[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [bt-spec] Re BTP Issue 103 (was issues 100, 101, 103 and 105)
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC