bt-spec message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [bt-spec] Issue 50: Default parameter values - Revised proposedsolution
- From: Tony Fletcher <tony_fletcher@btopenworld.com>
- To: BT - spec <bt-spec@lists.oasis-open.org>
- Date: Fri, 08 Feb 2002 18:00:11 +0000
Dear
Colleagues,
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC