Add configurability to `range` question type

[lognaturel]

As described in this forum post, add the following parameters allowed for range only.

Note that XLSForm uses _ as a separator by convention rather than - which is common for XForms attributes.

tick_interval

When present, its value MUST:

• be non-zero
• have an absolute value that is an exact multiple of abs(step)
• be less than or equal to abs(end - start)

tick_labelset

For a row with type range and non-empty tick_labelset parameter, the value of tick_labelset MUST match exactly one list_name on the choices sheet.

The name values for that list_name MUST be numeric strings that are multiples of step or tick_interval between start and end, inclusive.

See the XForms spec for additional validation.

placeholder

Value must be a multiple of step that is between start and end, inclusive

[lindsay-stevens]

1. About the tick_interval requirement "be greater than zero", should this be instead "be non-zero" to account for backwards ranges like -1 through -10 in -1 increments? Or are negatives not supported for ranges?
2. Will the new parameters be supported with other range appearances ('picker' and 'rating') or only 'vertical' and default (horizontal)?
3. It may help to note that the range question type is inclusive-inclusive or closed interval (both start and end are included in the range), I couldn't find that in the docs.

[lognaturel]

range.xlsx, https://staging.getodk.cloud/projects/11/forms/range/draft

I believed that backwards ranges weren't supported but it looks like Collect does support them. Additionally, Collect uses the absolute value of the step value which feels right to me.

Web Forms doesn't support backwards ranges. I'm also not entirely sure what it's doing with negative value steps. @garethbowen @latin-panda Does it feel right that both of these things should be supported? If so, let's file low-priority issues. I think we've already said that getodk/web-forms#714 is relatively high priority and looking at range in this context confirms that for me.

1. I think you're right about "non-zero". Unless there's an objection to supporting backward ranges and using the absolute value of the step size I'll update the docs/specs

2. Only for vertical and default/horizontal.

3. Yes, that sounds right, unless any questions/objections are raised I can update the docs/specs

CC @seadowg @grzesiek2010 for double check from Collect's perspective, particularly for 1. I'd also find it helpful to get a sanity check that Collect is doing what you expect for all ranges on the form I linked to at the top of the comment.

[garethbowen]

Does it feel right that both of these things should be supported?

Yes I think so.

Negative step: I've just done a quick test and the value is passed through to the primevue slider widget which freaks out when trying to change the value. So taking the absolute value would be a quick win.

Backwards range: Similarly to the negative step, the values are passed through, but the primevue widget can't handle it and no values except for max and min can be selected. This may take some more work to resolve.

[tiritea]

@lognaturel mentions (above):

numeric strings that are multiples of step or tick_interval...

So how is step and tick_interval related (and where is that relationship enforced)? Specifically (and putting exact start and end values aside for a moment) can I, say, have a step of 2 and a tick_interval of 3? Or must one (presumably tick_interval) be a multiple of the other (step).

[grzesiek2010]

CC @seadowg @grzesiek2010 for double check from Collect's perspective, particularly for 1. I'd also find it helpful to get a sanity check that Collect is doing what you expect for all ranges on the form I linked to at the top of the comment.

The form behaves as expected. When it comes to steps during validation of the range, one of the checks ensures that the step is not equal to 0 (if range is invalid it is disabled). However, it would be good to add this validation in pyxform as well. As you noticed, in Collect we use absolute values, so it’s not an issue there.