What high-level problem are you trying to solve?
Currently, in labels user can write instance() expressions to pipe data from other question responses or secondary instances (including entities) into a question or choice label (and a few other places). However, it can be difficult to reliably and quickly parse out where a complex instance() expression ends.
Any ideas on how ODK could help you solve it?
To solve this problem, and hopefully enable a lot of new and interesting features, a new expression delimiter syntax is proposed. The delimiter is double curly braces, reminiscent of Jinja or python f-strings. The delimiter can be escaped with a backslash.
The feature would support using variable references (e.g. ${my_question}) inside and outside of the expression delimiter, and using multiple delimited expressions in a string. Another way to think of it is, a shortcut for adding a calculate then a variable reference, but with the tradeoff that the expression would (probably, not yet tested) be evaluated when the item is displayed, rather than when the source item is saved - though if that distinction matters, the calculate method can still be used.
Columns to which this applies (including translation variants) are as follows.
- survey: label, hint, guidance_hint, constraint_message, required_message, image, big-image, audio, video.
- choices: label, image, audio, video (but not geometry).
The media columns are perhaps less straightforward since they still get a jr:// prefix to the value - for that kind of use case there is this proposal: Spec proposal: Media in external secondary intances
Example:
Hello World! I can add: {{ 1 + 1 }}
This sort of thing would be processed into:
<label> Hello World! I can add: <output value=" 1 + 1 "/> </label>
Since form clients can evaluate value contents as an XPath expression, the displayed result would be:
Hello World! I can add: 2
Since this is XLSForm syntax around a XForms feature, users could try out this method by manually editing an XForm as shown above.
At some stage the current instance() parsing would be deprecated in favour of this new method. In that case, migration would involve wrapping such usages in the delimiters: {{instance()}}.
Upload any helpful links, sketches, and videos.
Current work in progress: