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


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

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

Subject: RE: [bt-spec] BTP Issue 50 : Default parameter values

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


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

Powered by eList eXpress LLC