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

[Peter Furniss <peter.furniss@choreology.com>]

(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