First of all this doesn't address the text
"did we ever discuss"? My issue was also intended to start such a discussion
if one had not already occurred and been voted on.
Apologies - I misread your original
comment, taking the things in brackets to be your suggestions rather than
stating what was in the text (and was therefore my suggestion). No,
I don't think they'ed ever been discussed. I didn't mean to terminate discussion (even if I did
propose a solution)
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.
This doesn't address the underlying
question of "what is the right default value".
True - I was just trying to stick
a minor tidy-up on this bandwagon :-)
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.
OK, but again I'd like to have an
all-party discussion about what we think is the right default.
C)
it would seem nice to have the same default for the parameter whereever it
was used. It's a bit of a toss-up, but false perhaps has the
edge.
Not sure about this.
D)
report hazard default of false is definitely a good thing.
I disagree. In exactly the same
argument as for report_heuristic in the OTS, I think it should be a conscious
effort by someone to disable this, rather than enable it. Heuristics (or
hazards) potentially screw the entire application consistency, and I think the
majority of people would want to know about this by default. (It's a similar
argument to that used by JTA when it simply does not allow the possibility of
programmers to stop heuristic reporting.)
I was thinking that in this
loosely-coupled, inter-organisation environment not letting on about failures
might be more common, but I'm thing of the wrong relationship. This is
report-hazard on the terminator:decider relationship, which is most likely
(when interoperable) a delegation of coordination from the application (that
knows what's important) to the hub (which doesn't know what's important, but
does know how to do coordination).
I think there are three different places where they
may be a concept of default for these things - api, abstract message, xml
encoding - and there is no *necessary* commonality of what the default is. It
would obviously be confusing to switch the default between those, but it might
make sense for an api to insist the user says what they want (or even have
different calls) while the xml omits the common
value. Of course we aren't doing the api here
anyway.
Which would suggest there are actually three choices
for each: default is false, default is true, no default =
parameter/attribute must be present.
E)
All parameter names are supposed to hyphenated in the abstract messages
and thus in the XML. They should indeed be made consistent.
I'd like to propose the 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 a default of "false".
OK, but shouldn't this be
in a separate issue?
which ?
Peter
------------------------------------------
Peter
Furniss
Technical Director, Choreology Ltd
web: http://www.choreology.com
email:
peter.furniss@choreology.com
phone: +44 20 7670 1679
direct: +44
20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N
2JX