----- 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.