(or perhaps this is just a feature request for pyxform? or perhaps this is just an existing bug in pyxform?...)
What high-level problem are you trying to solve?
Basically the desire here is to resolve form question identifiers - eg ${foo} - to their respective XML instance element names - eg /data/foo - when adding custom instance attributes in the settings sheet, much as they are already resolved elsewhere in XLSForms.
Any ideas on how ODK could help you solve it?
Currently, when writing XLSForms, if you wish to reference specific questions (or calculations) in the form you can use the shorthand notation ${foo} to reference the specific question whose name=foo. This is pretty much universal behavior in XLSForms.
Further, when you add custom instance, binding or body attributes to questions - as described in the XLSForm spec - if you put ${foo} as the value for the attribute then it is correctly resolved to the appropriate XML element description in the resulting XForm definition. For example, the following XLSForm has two questions and I've added three custom attributes to each:
the resulting XForm looks like:
As you can see, the XLSForm ${name} reference has been correctly resolved to /data/name in the custom isParent instance, binding and body attributes in the final XForm.
However, for similar custom attributes against the main instance element, which are specified on the settings sheet using a column(s) with an "attribute::" prefix, these XLSForm ${foo} style references are not resolved (!); instead, the raw string is simply copied into the resulting XForm:
As written, the XLSForm specification appears to be non-specific about resolving ${foo} type references; however, other than apparently this one case with custom root instance attributes, it does appear to be almost universal behavior.
Summary
The desire here is to be able to reference form questions using the regular ${foo} XLSForm shorthand when setting custom XForm root instance attributes, just as you can for setting other custom XForm attributes in the primary instance, bindings, or body.
Its not clear if this was a deliberate decision not to [if so then I'd like to understand the rationale], or an oversight when implementing pyxform support for custom attributes by not including root instance attributes in scope, or pyxform should already be doing this and it is a bug.
Workaround
Note, you can manually resolve and enter the correct XML element name directly in the value instead, eg "/data/name", but this is awkward and atypical, and relies on the form builder being cognizant of the XML root element name [this is almost always "data", but it can vary...]. So it is much preferable to be able to specify ${foo} in this context as well.
