[business-transaction] BTP Issues email votes - 12 issues

[William Z Pope <zpope@pobox.com>]

This is a call for an email vote on the proposed issue resolutions 
included  below.
The voting period is one week, seven days, commencing Feb 21, 2002.
and closing at your local midnight on Feb 27, 2002.

To vote, a voting member must send an email to the chair and the recording 
secretary.
  chair: zpope@pobox.com
  secretary: peter.furniss@choreology.com

No need to include the text of this email.  Just indicate:
a) who is voting, 
b) each issue being voting on, and
c) the vote for each issue (YES, NO, ABSTAIN).
Feel free to add comments, especially for "NO" votes.

Issue list URL
----------
http://www.oasis-open.org/committees/business-transactions/issues.html

Issue Resolutions Attached
- Issue 2: Partial sentence in BEGUN
- Issue 3: Reference to "Full Superior"
- Issue 15: Negative reply to BEGIN
- Issue 16: Negative reply to REDIRECT
- Issue 19: FAULTS from RESIGNED
- Issue 39: Resigning Inferior
- Issue 50: Default parameter values
- Issue 60: address-as-role or role address
- Issue 67: "Hazard" from autonomous decision
- Issue 71: Messages for Terminator
- Issue 95: fault data for WrongState FAULT
- Issue 102: Is entity identity modification to be allowed in BTP.


Issues
--------------------------------------------------------------------


Issue 2: Partial sentence in BEGUN

--------------------
Description
In the abstract message definition for BEGUN, the paragraph on
address-as-inferior text ends half-way through a sentence.  

--------------------
Proposed Resolution

In the abstract message for BEGUN: 
  Remove the words "this parameter" at the end of the address-as-inferior
  paragraph.  

  Remove the inferior-identifier parameter 


--------------------------------------------------------------------

Issue 3: Reference to "Full Superior"

--------------------
Description
In Draft 0.9 after line 4389 reference to "Full Superior" should be "Cohesive
Superior". 

--------------------
Proposed Resolution

Change the text, "Full Superior" becomes "Cohesive Superior". 


--------------------------------------------------------------------

Issue 15: Negative reply to BEGIN

--------------------
Description

Is there a negative reply to the BEGIN?

--------------------
Proposed Resolution

In the abstract message definition of FAULT: 

  - change the initial description of the message to: 

         Sent in reply to various messages to report an error condition. The
         FAULT message is used on all the relationships as a general negative
         reply to a message.  

  - change the explanation of the meaning of WrongState to: 

        The message has arrived when the recipient or the transaction
        identified by a related CONTEXT is in an inappropriate state.  

In the definition of BEGIN, in the list of fault types, add 

        WrongState - only issued if there is a related CONTEXT, and the
        Superior identified by the CONTEXT is in the wrong state to enrol new
        Inferiors.  


--------------------------------------------------------------------

Issue 16: Negative reply to REDIRECT

--------------------
Description

Is there a negative reply to REDIRECT?

--------------------
Proposed Resolution

No change. 

--------------------
Supporting Material

Proposed solution to issue 15 : Negative reply to BEGIN , clarifies that the
FAULT message is the general negative reply message and can be used where
deemed appropriate).  


--------------------------------------------------------------------

Issue 19: FAULTS from RESIGNED

--------------------
Description

On Page 36 Para last Sentence 1 the current text reads:

   No FAULT messages are issued on receiving RESIGNED.

Is this true even if you did not ask to RESIGN?

--------------------
Proposed Resolution

Allow FAULT (wrongstate) and FAULT(general) as possible from RESIGNED, to be
sent to the Superior address.

In particular: At the end of the definition of the RESIGNED message replace:  

    No FAULT messages are issued on receiving RESIGNED

with

    Types of FAULT possible (sent to Superior address) 
    - General 
    - WrongState - if RESIGN has not been sent 


--------------------------------------------------------------------

Issue 39: Resigning Inferior

--------------------
Description

On page 16, change text to read: 
    "An inferior can remove itself from a given Superior:Inferior relationship
    by resigning (sending a RESIGN message).  If RESIGN is received from an
    Inferior, and the Inferior is allowed to leave the protocol, then the
    Superior:Inferior relationship is ended; the Inferior has no further
    effect on the behaviour of the Superior as a whole."   

--------------------
Proposed Resolution

No change

--------------------
Supporting Material

A Superior cannot reject RESIGN.  RESIGN can only be sent before and instead 
of PREPARED, and can cross with PREPARE.


--------------------------------------------------------------------

Issue 50: Default parameter values

--------------------
Description

Did we ever discuss default values for: 
(i) reply requested [false] 

(ii) response-requested [no default as far as I can tell, but I'd suggest true
     if sent before a PREPARE, and false otherwise.]  

(iii) report hazard [false] 

We also need to be consistent on the names: hyphenated or not. 

--------------------
Proposed Resolution

In the body of the text, abstract message definitions and the XML 

- Change "reply-requested" to "response-requested" for all uses of the
  parameter.

- "response-requested" has a default of "false" in all cases 

- "report-hazard" has no default value specified.  The parameter is mandatory 
  in the XML.  

- hyphenate all parameter names consistently .


--------------------------------------------------------------------

Issue 60: address-as-role or role address

--------------------
Description

The abstract message descriptions call the address parameters
"address-as-superior", "address-as-inferior", "address-as-decider", intending
to be clear that these are addresses the actor in question offers for that
role (i.e. as the target of particular future messages), given that the actor
may also offer other addresses for that role (or indeed the same address, but
for a different role)  

The xml constructs call these "superior address" etc., which is shorter, and
perhaps more message-oriented. A PREPARE for example travels from the
Superior (for this relationship) to the address-as-inferior of the Inferior of
the relationship.  

The names should be aligned or the difference justified in the text.

--------------------
Proposed Resolution

Use the form "address-as-<role>" consistently throughout the text including
the XML.  


--------------------------------------------------------------------

Issue 67: "Hazard" from from autonomous decision

--------------------
Description

Is it possible to have a "Hazard" as a result of autonomous decision?

--------------------
Proposed Resolution

In the abstract message section fro HAZARD 

- Delete the parenthesized text in the first paragraph. 
- Add the following explanatory note: 

      Note - If the Inferior makes its own autonomous decision then it signals
      that decision with CONFIRMED or CANCELLED and waits to receive a
      confirmatory CONFIRM or CANCEL, or a CONTRADICTION if the autonomous
      decision by the Inferior was the opposite of that made by the Superior.  


--------------------------------------------------------------------

Issue 71: Messages for Terminator

--------------------
Description

Because two different types of Terminators exist in BTP, it would be better to
tell which messages are for which type of Terminator.  For instance, CANCEL or
CANCEL/inferiors is only for composer? 

--------------------
Proposed Resolution

No change.  

This was addressed in the resolution of Issue 79: "Normalisation of the
message set".   Normalising the message set separated the names.
CANCEL_TRANSACTION is sent to any kind of Decider.  CANCEL_INFERIORS only to  
Decider-Composers. CANCEL is sent to Inferiors.  


--------------------------------------------------------------------

Issue 95: fault data for WrongState FAULT

--------------------
Description

In the table on page 60/61 of version 0.9 there is a table which contains
fault types and their respective fault data.  For the fault type "WrongState" 
there is no corresponding fault data.  

Is this an error?  Shouldn't it at least have a free text description, perhaps 
giving some information as to the unexpected state which resulted in the
error?  

--------------------
Proposed Resolution

In the FAULT message definition, in the table of "Fault type, Meaning, Fault
data", in the row for Wrongstate add in cell for the Fault data column "Free
text explanation".  


--------------------------------------------------------------------

Issue 102: Is entity identity modification to be allowed in BTP.

--------------------
Description

In migration (as with REDIRECT), shall it be possible for the identification
of the migrated entity (transaction, superior, inferior) to change, or shall
it be required that the same name be retained at each endpoint address  

--------------------
Proposed Resolution

Defer until after 1.0. 



====================================================================

BT TC Voting Rules
-------------------

Only eligible members of the TC can vote.  Every member of a TC has a
single vote.  Organizations do not vote in TCs.  Proxies are not
allowed in TC voting.    

Votes on technical and editorial issues pass when a majority votes in
favor.  The majority is more than half of the members who vote on the
issue, quorum is required.  Abstention are recorded and count towards
quorum.   If a majority is not achieved the motion will be rejected.
If quorum is not achieved it shall be as if the motion was not
proposed and the vote did not happen.

The chair may propose draft resolutions to the members of the TC for
discussion by mail, to entertain friendly amendments to such draft 
resolutions and make such changes as shall seem most likely to gain
general assent of the members of the TC, to put such resolutions as
seem to have gained majority assent to the members of the TC for a
vote by mail, and to conduct votes on such resolutions by mail.  

Regards,
TC chair

William Z Pope
zpope@pobox.com