Convenience function to improve constraint usability - inrange

[lognaturel]

[Originally filed as getodk/xforms-spec#75]

There are constraint functions that could help form designers build better forms more quickly. For example, @chrislrobert got an ask for something like Stata's inrange() function which would be easier to use than a combination of <= and >=. The user who made the ask has had to recover from several logic bugs introduced in complex constraint functions.

The question becomes how to pick a name and signature for this. It would be good for it to match some mainstream tool. @mberg has made the good suggestion to use Excel function signatures but unfortunately there doesn't seem to be a convenience function for range (this is the full Excel function list).

[chrislrobert]

FYI, I've been falling behind on some of these discussions -- but I am working in parallel. I have a meeting next week with the SurveyCTO meta-user who proposed some Stata-like convenience functions. We'll discuss some concrete proposals for Excel-based functions, to continue this thread. (He back-stops between 30 and 100 concurrent projects in dozens of countries, manages annual field coordinator trainings, and will generally have an excellent perspective on additions that could be particularly valuable.)

[chrislrobert]

Unfortunately, we got hung up trying to follow Excel. The trouble is that there is no Excel function that addresses the core need that spurred the original request: making constraints less error-prone. Our user has made the case that syntax-wise, what he's proposing -- even if it doesn't follow Excel or adhere to the XForms specification -- would not seem very confusing from a user point of view. His comments:

In terms of documenting syntax I think there is very little difference between for example selected(field, value) and inrange(field, minvalue, maxvalue).

inlist is a bit more different as the number of parameters are not fixed. But that is also the case for the concat() function so I think it could be done like this inlist(field, value, value, ...).

Then if one would like to use this as a constraint on a integer field for human age then the constraint restriction would be inrange(.,0,120) or inlist(.,-888,-999) where -888 and -999 means don't know and declined to answer.

Again, the original motivation was to provide convenience functions to help avoid some of the most common errors made in coding digital forms. And again, we cannot find existing Excel or XForms functions that meet the requirements. Thus, this is a classic case where we'd consider going all maverick and implementing SurveyCTO-specific functions. And it's not clear to me what the alternative pathway is.

If users repeatedly make mistakes, we have multiple reasons to want to help improve the situation. Here, we could conceivably do that via our GUI form designer -- but a lot of the issue is XLSForm users. So, a solution that also benefits them seems most appropriate.

Any ideas?

[lognaturel]

Apologies for not following up on this earlier, I didn't notice the notification for some reason.

I don't see any problem with using the Stata signature for inrange, it's pretty self-explanatory. There's no reason to match anything in XForm since it's just a convenience addition to XLSForm. The question was whether we could come up with something that might be better for some reason or a reason not to do this.