[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [bt-spec] Possible xml for btp node state
OK. Still want to see it deferred though. Mark. ----- Original Message ----- From: "William Z Pope" <zpope@pobox.com> To: "Mark Little" <mark_little@hp.com>; "Peter Furniss" <peter.furniss@choreology.com>; "BT - spec" <bt-spec@lists.oasis-open.org> Cc: "Geoff Brown" <Geoffrey.Brown@oracle.com> Sent: Tuesday, April 09, 2002 9:18 PM Subject: RE: [bt-spec] Possible xml for btp node state > > At the Redwood Shores face-to-face it was agreed as out of scope all of; > messages that transport the state info, access functions for the state > info, and basically anything except the format of the externalized state > info itself. > > =bill > > -----Original Message----- > From: Mark Little [mailto:mark_little@hp.com] > Sent: Tuesday, April 09, 2002 4:15 AM > To: zpope@pobox.com; 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? > > 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> > > > > > > > ---------------------------------------------------------------- > 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