Re: [bt-spec] Possible xml for btp node state

[Mark Little <mark_little@hp.com>]

> It has to be optional.

And required.

We are at a stage where we should be deferring non-essential issues
(something others, ourselves included, have already agreed to do). This is
not essential IMO and HP will not vote YES to this for the 1.0 specification
unless you can convince us otherwise.

Mark.

>
> Peter Furniss wrote:
>
> > I had assumed it would definitely be optional, being *a* way that the
state
> > could be serialised, but not required of all implementations.
> >
> > We might end up with three interoperation boundaries:
> >
> >  superior:inferior
> >  terminator:decider
> >  transferable state
> >
> > and an implementation might choose which of those to implement (and
> > potentially, which side of each, in some cases)
> >
> > Peter
> >
> > > -----Original Message-----
> > > From: William Z Pope [mailto:zpope@pobox.com]
> > > Sent: 08 April 2002 22:31
> > > To: Mark Little; Peter Furniss; BT - spec
> > > Cc: Geoff Brown
> > > Subject: RE: [bt-spec] Possible xml for btp node state
> > >
> > >
> > >
> > > Excellent question and I don't know the answer.  If we want to
> > > include this
> > > there has to be some guidelines for use.  Would there be a
> > > conformance item
> > > for this?
> > >
> > > The discussion at the Redwood Shores face-to-face was around being
able to
> > > share BTP state information.  So a simple minded translation of
> > > that is that
> > > this defines a state externalization format that can be used to
> > > share state with
> > > external entities.  I don't think that it's unreasonable to have
> > > an internal
> > > serialization format and another externalization format.
> > >
> > > =bill
> > >
> > >
> > > -----Original Message-----
> > > From: Mark Little [mailto:mark_little@hp.com]
> > > Sent: Monday, April 08, 2002 10:35 AM
> > > To: Peter Furniss; BT - spec
> > > Subject: Re: [bt-spec] Possible xml for btp node state
> > >
> > >
> > > This is for what reason? I certainly don't want the specification
> > > to tie my
> > > hands as to how I serialise and deserialise my state internally.
> > >
> > > Mark.
> > >
> > > ----- Original Message -----
> > > From: "Peter Furniss" <peter.furniss@choreology.com>
> > > To: "Mark Little" <mark_little@hp.com>; "BT - spec"
> > > <bt-spec@lists.oasis-open.org>
> > > Sent: Monday, April 08, 2002 3:14 PM
> > > Subject: RE: [bt-spec] Possible xml for btp node state
> > >
> > >
> > > > Mark,
> > > >
> > > > Yes, it was a bit veiled, and since you weren't able to be with
> > > us at the
> > > > Redwood City f-t-f, there is more of the context missing.
> > > >
> > > > The following includes elements of hearsay, so should be taken
> > > only as my
> > > > current understanding :-)
> > > >
> > > > The remaining issue (89, from Oracle), can be addressed by including
xml
> > > > specification that allows a btp actor to be transferred from
> > > one system to
> > > > another, in some way. Geoff Brown has been hoping to provide some
draft
> > > text
> > > > for this but has been snowed by other stuff.  I am not fully
> > > aware of all
> > > > the details of the requirement, but it did seem that defining an xml
> > > > serialisation of the state of a btp node (i.e. cooordinator,
composer,
> > > > sub-coordinator, sub-composer, participant) might be a useful
> > > component of
> > > > this. In editting the section in the normative text on persistent
> > > > information to take out the bits that were now in the model, I
> > > found I was
> > > > left with a text description of this information, and with Tony's
help
> > > we've
> > > > made a draft of the xml definition.  The cryptic remarks about "not
> > > anything
> > > > other than a Choreology suggestion" were because I didn't want to
claim
> > > that
> > > > it was the answer to issue 89, because I wasn't sure enough about
the
> > > > details of that. But I did mention it at the conference call, and
people
> > > > asked us to make available what we had.
> > > >
> > > > Peter
> > > >
> > > >
> > >
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >
> > >
>
>