Add relative referencing

[mberg]

The latest Javarosa version for ODK Collect now has

current()/../../ref syntax. To do relative referencing of fields in an XLSForm. One could theoretically replace all the ${fieldname} expansions with this syntax and then we would have reliable referencing of fields within the current repeat group. This is not documented anywhere (yet).

[MartijnR]

related: SEL-Columbia#91

[ukanga]

Are there concrete examples of how and where this should be used?

@MartijnR @mberg @yanokwa @lognaturel

[lognaturel]

I'm going to need a little help catching up to the overall goals and desired end-state.

Currently, ${fieldname} expansions are always done to absolute paths, even in repeats. That means if there's a form called roster with a repeat called friends with a firstname field in it, ${firstname} will always expand to /roster/friends/firstname. In true XPath this should either mean the first friend's name or a list of all friends' firstnames. In the ODK world, that ends up meaning the current friend's firstname when it's used in the repeat. This is explained at https://opendatakit.github.io/xforms-spec/#a-big-deviation-with-xforms

I understand this discrepancy is inelegant but it's not immediately clear to me whether it results in any lack of expressiveness or other big issues. Does it?

There's some desire to try to rectify this eventually. What would this open up? The ability to access the full list of repeats in the repeat? Something else? Using relative references in forms moving forward means that the behavior of absolute references could theoretically be changed at some point in the future.

Am I understanding correctly? Is there more to this I have missed?

[MartijnR]

or other big issues. Does it?

Only our embarrassment I think. 😰

Using relative references in forms moving forward means that the behavior of absolute references could theoretically be changed at some point in the future.

I think this is the argument for the fix. I cannot think of any new functionality this adds, or any changes to existing functionality this produces. We're just improving the XForms output and eliminate the old incorrect syntax in 100% of the new forms. The relative syntax should already be supported in our clients. (Note, we could clean up the spec years before we actually drop support for the incorrect syntax.)

[lognaturel]

Thanks, @MartijnR! Always great to clarify that we're on the same page.

I'm all for it. The only issue I see is with choice filters as I commented in #187 (comment). Could we perhaps start by not using relative paths for choice filters while things are figured out on the Javarosa side? I believe they should be ok everywhere else though I think we should all do some pretty thorough client verifications before flipping the switch.

[MartijnR]

Yes, of course we give you a few days ;)

Hard to believe that the original pyxform issue has been open since April 2013!

[lognaturel]

😄Generous!

This is esoteric stuff with no immediate user benefit so it's harder to rally energy around it, I think! In our collective defense, it's not like we've been sitting idle in the interim... 😉

[lognaturel]

For posterity's sake since I realize this isn't explicitly documented here though it is discussed in linked threads -- there is a big user benefit and that is to be able to use choice filters in repeats. Currently those fail because the absolute reference is interpreted as a nodeset. Having pyxform output relative references would make this easily in reach. But currently Enketo and Collect disagree with how to interpret current() in a repeat (Collect is wrong -- see getodk/javarosa#293).