RE: [business-transaction] PREPARE_INFERIORS

[Mark Potts <mark.potts@talkingblocks.com>]

2 choices as I see it.

1)We could have an addendum or "known issues" section to the spec to address
this and mark them for being addressed in the next version of the spec. If
they are show stoppers however er I don't see any way of avoiding addressing
them somewhere in the spec directly.

2) Address all priority issues in the spec as Mark says even if it is the
day before ( i.e. technical : a question of what the specification should
mean/what the protocol should do and/or with substantial implications on
implementation ).

Of course we could do both!

-----Original Message-----
From: Mark Little [mailto:mark_little@hp.com]
Sent: Tuesday, January 22, 2002 1:42 AM
To: Peter Furniss; BTP
Subject: Re: [business-transaction] PREPARE_INFERIORS


> The list is closed for new technical issues. I've been trying to avoid
> getting to issue 100, but there are bound to be editorials, so we're going
> to go over, aren't we.

I think that it's useful to close the list prior to a release of the spec.
However, we can't prevent new issues from coming up and some of them (and
I'm not saying the issue I raised falls into this category) will need to be
addressed before the spec. can be released. Do we need a formal rule for
"bumping" issues across release boundaries? I'd hope that such issues would
be blatantly obvious as to their importance, but you never know.

Mark.

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>