[bt-spec] Issue 50: Default parameter values - Revised proposedsolution

[Tony Fletcher <tony_fletcher@btopenworld.com>]

Dear Colleagues,

 

Issue 50: Default parameter values

Status: open (19 Nov 2001)
Date added: 8 Nov 2001
Submitter: Mark Little, HP
Category: technical
Submitter's identification: #18
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]

Do we not also need to be consistent on the names: hyphenated or not.
Line: 1343, 1419

Peter wrote:

  A) there is no obvious reason why we have "reply-requested" for ENROL and the *_STATUS messages and "response-requested" for RESIGN. They should have the same name. "response-requested" seems more general, especially for *_STATUS which may generate all sorts of things.

B) we can't have a default that changes depending on what has been sent/received because RESIGN can cross with PREPARE - the RESIGN message would be sent with a default of true and arrive with a default of false.

C) it would seem nice to have the same default for the parameter wherever it was used. It's a bit of a toss-up, but false perhaps has the edge.

D) report hazard default of false is definitely a good thing.

E) All parameter names are supposed to hyphenated in the abstract messages and thus in the XML. They should indeed be made consistent.

Proposed solution::

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

hyphenate all parameter names consistently

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

"report-hazard" has  no default  value specified.

These changes to be carried out on the body of the text, abstract message definitions and the XML

 

Note:  The TC might wish to discuss the default value for "report-hazard".  The original proposed solution had it set to "false".   Mark (Little) requested that it be changed to true - and of course there is the third option of no default - the value must always be explicitly set - which is what the revised proposal has.

 

The 9.1.2 version of the BTP spec has the default value specified as "false" on the CONFIRM_ONE_PHASE message and no mention of a default for other occurrences in the abstract message definitions.  The XML schema does not set a default value  for this element anywhere as far as I can presently see.

 

I guess an argument for using false is that a decision can be reported more quickly in some cases - once a decision is made, rather than having to wait for all inferiors to report in.  Perhaps this is an area where we should let the nature of the application dictate, which is why I am now suggesting that no default value is specified in the BTP specification.

 

Best Regards     Tony

A M Fletcher

Choreology Ltd., 13 Austin Friars, London EC2N 2JX     UK

Tel: +44 (0) 20 76701787         Mobile: +44 (0) 7801 948219

tony.fletcher@choreology.com     (Home: amfletcher@iee.org)