----- Original Message -----
Sent: Wednesday, April 24, 2002 2:35
PM
Subject: RE: [business-transaction]
Regarding issue #89
I think this issue comes in at two levels - a
scope/procedure/timing issue, and a technical/content/detail one.
However, they aren't entirely separable.
The technical content of what is proposed can be
described in the diagram attached. The existing actors are already well
defined. All that is proposed is that we define an xml representation of
the state of a transaction node, in their five flavours. How that
serialisation is invoked, or how the xml format is reincarnated to be
active or how the serialised state is passed around or stored or how
multiple nodes are presented or transferred are not proposed at this
stage. It could be that those are never defined in a btp spec, but
some other specification details with the requesting, transfer and
reincarnation of entities whose state can be represented as xml - in which
case that document would reference this schema as how to represent btp
actors that were involved. Or future btp work might cover this (for a
different use case), which might mean there were new roles - but even they
would be kind of sideways to the existing ones.
In fact, re-reading Sazi's paragraph, it answers
its own question: "
there is nothing to do other than agreeing on a form that we think that a
BTP system will externalize its state". That is precisely what we are
talking about.
There are some detailed questions about the
content of the xml document itself - where implementation or application
specific information is included; whether the serialisation declares its
position in the tree explicitly (e.g. with a role type element) or if
it is implicit in whether superior and inferior relationships exist. But
the semantic content is well understood - and has been for a very long
time, since it's essentially the same for any 2pc transaction node (at
least for presume-abort).
Whether we end up with exactly the best xml
definition for this isn't certain, but then the same applies to all the
rest of the protocol. I think we generally expect that 1.0 won't be the
final word. Including a serialisation format now means that stands a
chance of getting tested along with everything
else.