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

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [business-transaction] Votes


Votes for myself, Doug Bunting, the one sending this message, et cetera.
(Should be fairly obvious since OASIS process doesn't support proxy votes).
Sorry that I'm noticing additional issues with 50 rather late.

- Issue 2: For
- Issue 3: For
- Issue 15: For
- Issue 16: For
- Issue 19: For
- 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.

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

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

- Issue 102: Can I defer my vote to defer? (probably not :-)  If not, For.

thanx,
    doug




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC