select_multiple from repeat not supported

[yanokwa]

You can select_one from repeat

select_one ${member_name}

When you select_multiple from repeats

select_multiple ${member_name}

You get an unhelpful error message

The XLSForm could not be converted: '${member_name}'

My guess is that this limitation is there because of space-delimited lists.

[lindsay-stevens]

Yep https://forum.getodk.org/t/populating-answer-choices-from-household-roster/32728/3

The reason we don't currently allow select_multiple from repeat is that it's really easy to end up with results that are hard or impossible to analyze if the field that is uses allows spaces. (e.g. "Marie Pierre Denis" could refer to one, two or three people who were selected). We could consider adding it.

Some ideas for allowing it

• cases that could be proven to be safe, like if the source item data type does not allow spaces (integer, date, etc) or is an internal select_one with no spaces in the choice names (related: Warn when a choice name for a select_one has a space in it #370).
• any case but with a warning that the choice values must not contain spaces otherwise the data will difficult to interpret.
• any case but with new select_multiple parameter separator which Collect/Webforms should use to delimit the values, e.g so a user could choose a somewhat less likely character like separator=|.
• any case but Collect/Webforms applies an escape character (or some other substitution) to spaces in the selected values.

[yanokwa]

Not a lot of great options here. My initial reaction is that we should allow it if cases can be proven safe, but I don't think that's something we can know at form conversion time. Am I right, @lognaturel?

[tiritea]

FWIW, I dont think anything that fundamentally changes what XForm considers the de facto separator in a multi-select response should be changed; for better or worse, it is what it is: a space. And there is probably a lot of existing form code out there that is based upon it being a space separated list (I know I've leveraged this many times for different purposes). Also, changing the separator to something else, something that might be less likely to be included in a user's text response (eg "|"), doesn't really change anything - it still remain possibles for this delimiter char to be inadvertently populated in a user's text response that so happens to be targeted by a select-from-repeat.

I agree that pyxfrom should permit select_multiple from repeats. But this should not be at the expense of changing something intrinsic to XForms. I definitely think at least an explicit pyxform warning is needed, but even in cases when it remains possible for the target repeated XML instance element to contain a space (eg the form writer doesn't include a constraint preventing such), it is still possible for them to add an explicit translate() calculation to remap this space to, say, an underscore, and then use this translated, calculated repeat element name elsewhere as the target. That is, there is probably a ready workaround for the issue, assuming the form writer is aware of the problem.

[tiritea]

Perhaps another approach, one that could suit both select_one as well as select_multi, might be to envision a way for the select-from-repeat to be able to provide a way to (optionally) specify a different repeat element to use for the actual name value, as opposed to re-using the same element for both the derived select's label and name.

That would also directly permit extracting (by selection) the particular value of interest - from a dataset collected by a repeat - rather than then having to subsequently look it up in a separate operation [using a nodeset filter against the repeat group]. I need to think what that'll look like in XForm... Scratch that; this usecase probably makes it far too easy to select values that wont then be unique (unless the user's repeat somehow ensures some degree of uniqueness in this field) making it impossible to then disambiguate what repeat element was probably selected.

.. ala what @lognaturel already apparently covered here: https://forum.getodk.org/t/select-one-from-repeat-different-value-and-label/39195/2 (lol!)

[lindsay-stevens]

@yanokwa some more ideas

• do not use values directly but store a stable surrogate key like the itemset's nodeset position(), or XPath reference, or the value digest(), or a new unique ID attribute made by Collect/Webforms, or allow ./value/@ref to be user-specified.
• use the XForms 1.0 spec itemset copy feature to store the whole selected element in a nodeset rather than a space-separated list - actually it seems the spec for multi-select xforms:listItems recommends that in preference to space-separated lists.