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

[William Z Pope <zpope@pobox.com>]

Forwarded to to the bt-spec list for Geoff.

-----Original Message-----
From: Geoffrey Brown [mailto:Geoffrey.Brown@oracle.com]
Sent: Monday, April 08, 2002 7:27 PM
To: Peter Furniss
Cc: zpope@pobox.com; Mark Little; BT - spec
Subject: Re: [bt-spec] Possible xml for btp node state


It has to be optional.

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

Attachment: Geoffrey.Brown.vcf
Description: text/vcard