OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[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