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

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

Issue 100 was about separation of "delivery" and "payload" parameters.

After chasing this round here a bit, it seemed it was a bit doubtful whether
it was worth creating a separate xml block - there are never more than two
fields, often only one and they will quite often both be absent (because
implicit in the carrier protocol). But there is certainly a semantic
difference, and possibly some implementation convenience in keeping them
near each other, and at one end of the message.

So I've put in a proposed solution of "colouring" the delivery parameters in
the xml in the text by giving it a darker background, and similarly in the
abstract messages, and moving all of them to the end of the message. Bit of
explanatory text.

Note that identifiers (either senders or receivers) are payload parameters -
although they might, in some implementations, be used for delivery to the
target object, they are unchanged if the transmission method is different,
whereas (in a multi-carrier environment) the delivery parameters can change.
Also the set of BTP addresses in CONTEXT,ENROL, BEGUN and REDIRECT are
payload parameters, because they refer to future messages, not just this one
and its reply.

See issues list and 0.9.2.4 for the proposed solution.

Peter

> -----Original Message-----
> From: Peter Furniss [mailto:peter.furniss@choreology.com]
> Sent: 13 March 2002 22:43
> To: BT - spec
> Subject: [bt-spec] Re BTP Issue 100 (was issues 100, 101, 103 and 105)
>
>
> As referred to in the conference call, another message that Mark
> asked me to
> forward, arising from the same discussion.
>
> -----Original Message-----
> From: Mark Little [mailto:mark_little@hp.com]
> Sent: 13 March 2002 15:08
> To: Peter Furniss; WEBBER,JIM (HP-UnitedKingdom,ex1)
> Cc: Alastair Green; Bill Pope; Mark Little
> Subject: Re: issues 100, 101, 103 and 105
>
>
> > Ok, that's not quite how I'd understood 100 at the time it came in our
> > earlier argument. How do you see that separation being made in the
> document
> > ?  In the model (I have to write the section on binding) ? By
> ordering or
> > separating the parameters of the abstract messages ?
>
> It seems to me that many of the messages have distinct payload
> and delivery
> components. Things like target-additional-information, responder-address,
> etc. aren't strictly necessary to process a STATUS message, for
> example. The
> payload to STATUS is really the status-value. So, someone wanting
> to write a
> participant that responds to a status request may only need to worry about
> how they create the <btp:status-value></btp:status-value> component, and
> some underlying invocation component will deal with the rest of the XML
> (pipe-line like).
>
> What I'm worried about (and this has been evidenced by the fact
> that many of
> the people we've talked to have also expressed the same concern) is that
> people looking through the document simply to see what an "actor" needs to
> do to become two-phase aware (for example) are typically looking
> at it from
> the high-level "user" point of view and get turned off by the (relative)
> masses of extraneous XML. They can't see the wood for the trees.
>
> Now, how we separate these so that different implementers/users can see
> exactly what they need to is probably a matter of personal preference. A
> couple of ways that spring to mind include:
>
> (i) colour code the XML
>
> (ii) have two XML blocks for each message; one which is labelled
> payload and
> only describes the payload(!), and the other that is (for
> example) labelled
> delivery information and contains a hole where the payload should go.
>
> Other solutions are possible and equally valid.
>
> >
> > > 101 and 102 we can defer.
> > >
> > > Not addressing 103 now may lead to backward compatibility issues if we
> do
> > > adopt it later, though I believe we can solve it in a manner that
> > > shouldn't
> > > cause problems. As to whether or not it should be deferred, I'll
> > > get back to
> > > you on that one later today.
> >
> > ok
>
> You should have the proposal by now.
>
> Mark.
>
> ----------------------------------------------
> Dr. Mark Little (mark_little@hp.com)
> Transactions Architect, HP Arjuna Labs
> Phone +44 191 2606216
> Fax   +44 191 2606250
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>