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

[Mark Little <mark_little@hp.com>]

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