Taking a quick step back from the implementation for a moment, I want to make sure we're on the same page when it comes to user experience. Clients would implement an interface that would let users set arbitrary key-value pairs. The details would be up to the client implementation but this JSFiddle shows roughly what I have in mind. Here's a screenshot:
There would be some validation to make sure that the keys are valid identifiers according to whatever backing scheme we implement, that they're unique, etc and the values would be freeform. Are we on the same page there?
Artificial Secondary External Instance Implementation
I haven't had the opportunity to think deeply about artificial secondary external instances yet. I believe the concept is that backing data can be anything (Shared Preference key-value pairs in Android for example), but that it is accessed in a standardized way (XPath). Does that sound right, @martijnr? For example, the virtual XML equivalent to my screenshot above would be something like:
<session>
...
<data>
<team>purple</team>
<favorite-food>lasagna</favorite-food>
<todays-code>7756</todays-code>
</data>
...
</session>
But it doesn't ever really have to be XML. Since custom values would have no children and no known names, there's no real meaningful XPath queries to write over the virtual instance anyway. Am I getting this right?
Is data the right parent node name or might there be advantages to going even more specific with something like client-custom-values? Or perhaps that would be a child of data?
jr:preload Implementation
jr:preload is a little unfortunate because it defines new syntax where using an artificial secondary external instance wouldn't have. However, the mechanism exists. Couldn't another option be to say that jr:preloadParams can have arbitrary text and will fetch a custom value if available. For example, <bind nodeset="orx:meta/orx:team" type="string" jr:preload="property" jr:preloadParams="team"/> would allow me to populate the orx:meta/orx:team node with the value I specified in my JSFiddle above.
Likewise. So perhaps this isn't a great approach but it does have the advantage of being consistent with past decisions?
XLSForm interface
I also want to give some thought to what XLSForm users experience. This will hopefully also give some ideas for other form builders. The best I'm coming up with currently is to build on the idea of artificial instances by allowing some prefixes in the ${} syntax. So for example, I would do something like
+-----------+---------+-------+-------------------------------+
| type | name | label | calculation |
+-----------+---------+-------+-------------------------------+
| calculate | my-team | | ${/client-custom-values/team} |
+-----------+---------+-------+-------------------------------+
We could make the prefix anything that is user friendly, in this case I used /client-custom-values/ as an example but it doesn't necessarily have to be related to the XForms approach.
I think that in the case of a jr:preload-based implementation, an intermediary calculate as described above would be necessary. But in the case of an implementation based on artificial secondary instances, it might be possible to use the value directly as in
+-------------------+-------------------+---------------------------------------------------------+
| type | name | label |
+-------------------+-------------------+---------------------------------------------------------+
| select_one yes_no | team-confirmation | Are you part of the
| | | ${/client-custom-values/team} team? |
+-------------------+-------------------+---------------------------------------------------------+
I'm imagining this would translate to
<bind nodeset="/my-form/team-confirmation" type="select1"/>
...
<select1 ref="/my-form/team-confirmation">
<label>Are you part of the <output value="jr://instance/session/data/team"/></label>
...
I'm less sure about this -- it's not totally clear to me what's allowed with output.