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

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

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