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

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

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