Improve constraint usability through functions like inrange

[lognaturel]

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. I'm sure that kind of issue is pretty common and is worth addressing.

One option would be to add those as custom XPath functions to this spec but as they only add user-facing convenience, perhaps they could instead be added at the XLSForm level as syntactic sugar for the comparison operators.

[mberg]

If we do this we might want to support a subset of excel functions that translate to xform comparison operators. Nyaruka has built and maintains a great library here. I'd prefer this vs. stata as these operators are a lot more mainstream https://github.com/rapidpro/expressions

…

On Tue, Jan 17, 2017 at 11:14 AM, Hélène Martin ***@***.***> wrote: There are constraint functions that could help form designers build better forms more quickly. For example, @chrislrobert <https://github.com/chrislrobert> got an ask for something like Stata's inrange() <http://www.stata.com/help.cgi?inrange%28%29> 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. I'm sure that kind of issue is pretty common and is worth addressing. One option would be to add those as custom XPath functions to this spec but as they only add user-facing convenience, perhaps they could instead be added at the XLSForm level as syntactic sugar for the comparison operators. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#75>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADiQY8vovOXLqhWEEEm7McgwN2j5tsSks5rTHhRgaJpZM4LlV4G> .

[lognaturel]

I agree we should discuss what the actual functions would be and what they correspond to. The Stata example was what that particular person mentioned. Supporting Excel functions seems like a good idea but I think this is the complete list and that there is no convenience function for range.

In general, though, does the idea of doing some of this at the XLSForm level appeal to you? If so, I'll file over there. @chrislrobert, I can't remember, were there more of these you heard would be useful?

[chrislrobert]

Yes, definitely, there are many excellent candidates for such "convenience functions." We've just never seriously considered them, and the inrange was just an example of the kind of thing we could do. If we had a mechanism for adding them that wouldn't wreak havoc for cross-tool compatibility, I bet we could come up with a solid list of candidates. BTW, the idea of following Excel is brilliant.

…

On Jan 17, 2017 3:51 AM, "Hélène Martin" ***@***.***> wrote: I agree we should discuss what the actual functions would be and what they correspond to. The Stata example was what that particular person mentioned. Supporting Excel functions seems like a good idea but I think this <https://support.office.com/en-us/article/Excel-functions-alphabetical-b3944572-255d-4efb-bb96-c6d90033e188> is the complete list and that there is no convenience function for range. In general, though, does the idea of doing some of this at the XLSForm level appeal to you? If so, I'll file over there. @chrislrobert <https://github.com/chrislrobert>, I can't remember, were there more of these you heard would be useful? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#75 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIO0Hp70OLEq0NPnbdv3eKx2rYHI7porks5rTIEigaJpZM4LlV4G> .

[MartijnR]

I'm all for adding some of these convenience functions on the XLSForm side and leaving them out of XForms. Something similar is also happening with the new GUI form builders that include formula builders (i.e. creating simple shortcuts in the UI that produce complex valid XPath expressions in the background).

Two advantages of choosing the XLSForm route, when it makes sense, is that we stay closer to XForms 1.0/1 and to CommCare (who do not seem to add custom functions) and there is no risk getting in trouble with function name collisions (in particular because we sort of decided not to namespace custom XPath functions).

(FWIW, Enketo does similar processing of some custom functions such as indexed-repeat() to re-write them as pure XPath 1.0 before evaluating them.)

[lognaturel]

Awesome! Let's move the discussion over to XLSForm/xlsform.github.io#78 then.