[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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? Not only that, but also what message(s) are to be added to support this? How do I get the serializable form if I'm some external agent? What are the export/import messages and criteria? > > 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. I don't have an issue with adding this, but I would prefer that it happens post 1.0. This is potentially a big change (and it could be an important one), so rather than rush it through I'd like to see much more discussion on this and get it right first. At the moment I don't see enough calls for this from other committee members or an indication that a vote on this will be an educated vote. Mark. > > =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> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC