[bt-spec] Re: [business-transaction] Votes

[Doug Bunting <dougb62@yahoo.com>]

Peter,

For issue 39, I misread the issue description and didn't catch the "no
change" final proposal.  Even if superiors can't reject RESIGN for their own
purposes, RESIGN could arrive out of sequence (after PREPARED or mentioning
an unrecognized identifier or two).  Addition of words about "allowed to
leave the protocol" better covers this case.  So, you're right, I'm against
closing this issue and for the original proposal.

On issue 50, report-hazard is described at lines 1738-1744 (missing hyphen),
2121-2129 (missing hyphen, specifically mentions waiting for inferior
replies), 2157-2166 (as partially quoted below and which misses the success
case if report-hazard is true), 2184-2187 (reasonable), 2220-2225 (similar
to 2121-9 text), 2283-2287 (similar to 2184-7) and 2352-2357 (similar to
2184-7).  The text in each description is slightly different and should be
better aligned.  None of these descriptions mention how errors encountered
while applying a decision are handled in false case (logging, et cetera
could be mentioned) and some miss what occurs in the true case when
everything works.  I didn't see anything saying (in reference to your point
4) TRANSACTION_C*D would always be returned except with caveats about the
decision in the report-hazard false case.

Oh, that's right, lines 2224-5 say CANCEL_TRANSACTION/report-hazard=false
"immediately" results in a TRANSACTION_CANCELLED response.  Is that
incorrect?  I suspect it's right and lines 2157-66 are the ones most in need
of change.

Yes, please add my comments on issue 95 as a new (deferred) issue.

thanx,
    doug

----- Original Message -----
From: "Peter Furniss" <peter.furniss@choreology.com>
To: "Pope William Z" <zpope@pobox.com>; "Doug Bunting" <dougb62@yahoo.com>
Cc: "BT - spec" <bt-spec@lists.oasis-open.org>
Sent: Wednesday, February 27, 2002 6:28 PM
Subject: RE: [business-transaction] Votes


(dropped cc down to bt-spec list)

> - Issue 39: For, assuming I'm correct in thinking the change would be to
> replace "If RESIGN is received from an Inferior, the Superior:Inferior
> relationship is ended; the Inferior has no further effect on the
> behaviour of
> the Superior as a whole." on page 17 in the 0.9.2.1 version with the given
> text.

Hmmm - No.  The proposed resolution is to make no change - the text in
0.9.2.1 stays in. If you follow the discussion Mark and I had (in November),
the issue was raised in the belief that resign could be rejected by the
superior, but there is in fact no such capability.

So, that would appear to make your vote "against".

> - Issue 50: For, with caveat that making a parameter required in one XML
> binding doesn't require that handling in other bindings.  I'd prefer the
> addition of words in the section introducing bindings requiring
> all bindings
> make the report-hazard parameter mandatory.
>
> Separately, does our specification say enough (or is it
> consistent) about the
> report-hazard="false" case?  Lines 2157 through 2161 currently say:
>     If a confirm decision is made and "report-hazard" was "false", a
> CONFIRM_COMPLETE
>     message shall be sent to the "reply-address".
>
>     If a cancel decision is made and "report-hazard" was "false", a
> CANCEL_COMPLETE
>     message shall be sent to the "reply-address".
> which implies CONFIRM_COMPLETE won't be sent even if no inferior reports a
> problem and everything goes swimmingly.  Other sections of the
> document imply
> the *_COMPLETE messages are always sent whether or not inferiors report
> problems.

1. those should be TRANSACTION_CONFIRMED and TRANSACTION_CANCELLED - the
*_COMPLETE message names were an interim suggestion that got dropped. I
thought I'd caught them all.  I'll scan for COMPLETE.

2. the bits you quote cover the report-hazard false, and always produces one
or other of the TRANSACTION_C*ED messages

3. You are right that for the case where report-hazard is true, it doesn't
say what happens if everything does what they're told

4. If the other sections of the document say you always get
TRANSACTION_C*ED, then they are wrong (or, at least, simplifying with some
loss of accuracy). Can you say where it says this ?



> - Issue 60: Against, prefer role-address
> - Issue 67: For
> - Issue 71: For
> - Issue 95: Abstain.  I would much prefer free text explanations
> were directly
> supported by the FAULT message.  That would reserve fault-data
> for additions
> specific to a fault type and allow additional text no matter what the
> problem.  My preferred resolution would add a free-text parameter (or some
> such) to the FAULT message and remove "Free text explanation" from the
> fault-data column wherever specific material isn't required.  Abstaining
> because this resolution at least allows text with the WrongState
> fault type.

That sounds a good idea, but it doesn't quite fit with any existing issue.
It would seem an appropriate candidate for a new issue, which (in accordance
with Bill Pope's proposal on the conference call today) would enter the list
as deferred, and require a considered decision (vote) of the tc to be
considered for 1.0.  Do you want to put it in as such ?


Peter