Consider: move away from search()?

[dave-mills]

We use search() extensively in our ODK forms. All the customisable datasets that come from the database are brought into the ODK forms as csv files and referenced via search() or pulldata(). There are many benefits to this:

a) It's easy to use the same ODK form with different datasets - e.g. different respondents, crops, agricultural practices for different teams in a project.
b) The csv files can have any arbitrary data in them, which can be included and referenced in the form with pulldata().
c) It supports multiple languages - in wide format (1 column per language (label_en, label_fr, etc), or long format (1 row per item/langauge combo - more messy but very useful if we don't know the list of required languages in advance).

But there are some drawbacks to this:

1. search() doesn't work with Enketo, which means none of our forms work with Enketo! And this will not be fixed.

EDIT: I wonder if it will work with the new ODK Web forms in development... https://forum.getodk.org/t/coming-soon-powerful-new-web-forms-for-odk/46786

2. I think search() doesn't use the standards that the rest of Xforms are based on - it was some custom implementation. The ODK core team really want to get rid of it, but haven't yet because there isn't a clear alternative.

Alternatives:

• select_one_from_file: This is the recommended approach according to the documentation and ODK team. The big problem is that it doesn't support multiple languages! (https://docs.getodk.org/form-datasets/#form-datasets)
• build our systems so that the "customised" lists are written into the XLSform! This would mean maximum compatibility, but would be harder to code and possibly more cumbersome?