Without realising, I named a group 'start', and also included the metadata start. I uploaded drafts, tested, published and didn't hit any errors.
When I later tried to update to use ${start} in the instanceName I then hit an error on upload
The XLSForm could not be converted: There has been a problem trying to replace ${start} with the XPath to the survey element named 'start'. There are multiple survey elements with this name.
Perhaps the validator should have prevented upload earlier to prevent duplicate names across repeat/group and field?
2. What steps can we take to reproduce this issue?
test a form that has a start metadata any field as well as a repeat or group named identically, first without referring to ${the_test_field} anywhere, and then by referring to it.
3. What have you tried to fix the issue?
resolved by renaming group.
I tested various combinations and found two cases where identical names don't error:
two identical group names - validator errored as expected
a group and a repeat with identical names - validator errored as expected
a group named identically to a non metadata field that was referred to elsewhere - validator errored as expected
a repeat named identically to a non metadata field that was referred to elsewhere - validator errored as expected
a group named identically to a non metadata field that wasn't referred to anywhere - validator did not error
a repeat named identically to a non metadata field that wasn't referred to anywhere - validator did not error
4. Upload any forms or screenshots you can share publicly below.
I tried replicating the same combos, my best guess is that in a group or repeat, the field name inherits the parent name, altering it’s full xpath tag to /data/group_name/field_name (same applies to data exports with group names) and would need a full xpath otherwise throws an error when referred to (in case of duplicated field names | odk needs to know the correct reference to make). So getting the value from desired would require a full xpath i.e.: /data/group_name/field_name if located in a group or /data/field_name for the duplicate outside group/repeat structures. In a repeat an indexed-repeat() would be required.
Hoping this helps narrow the strategy. It would indeed be great if validator can warn name-based duplicates regardless of location alternatively extend the allow_duplicates in settings to field names too.
@jules_rugwiro’s explanation is exactly right – the underlying ODK XForms spec has no requirement for field names to be unique as long as paths are unique and so XLSForm doesn’t require uniqueness.
I think it would be hard to change because existing forms might stop being valid. That said, we could consider a warning or an explicit setting. How important does it feel @ahblake? I would expect this kind of issue to be generally discovered while iterating on an initial draft. Definitely annoying but likely not deeply harmful. It would be more problematic if someone were to edit an existing form and discover a conflict.
We’ve been thinking about these uniqueness rules in pyxform recently and @Lindsay_Stevens_Au has written his own summary of uniqueness rules at https://github.com/XLSForm/pyxform/pull/778, we’re contemplating whether/how this should be documented so please let us know if you have suggestions.
It's not important to me at all, and I only hit it as I was quickly throwing a form together to test something and named the group 'start', usually I prefix groups and other types to make them easy to ID, like grp_, rep_, calc_ and normally have conditional formatting on the name column to highlight any duplicates at all.
I had considered that there was a unique xpath so that's why it validated & published initially, but thought that as the pyxform ${} notation doesn't require the absolute path, you might be able to catch yourself in a trap with a duplicate and then make a modification after publishing referring to one of the duplicates that would require a change in form field/group/etc naming, causing other downstream pain. I did however miss that you can have duplicate field names also if they have unique paths, so it's not a repeat/group-field issue, just an potential annoyance.
If there is any change that's made, a warning (like the yellow "Please correct the problems and try again. If you are sure these problems can be ignored, click the button to update the Draft anyway:") would be more than enough, just to advise that there are duplicate name values across all fields/groups/repeats, and you can continue if desired
Thanks for the link, this part explains;
question and group names must be unique within their context i.e. nearest parent group or repeat, or the survey if not inside a group or repeat.
if pyxform reference variables "${}" are used, referenced name (question, group, repeat) must unique anywhere in the survey
if this is not possible then the pyxform reference can be replaced by a manually written XPath expression..
I would like to suggest: A warning or even an error msg if a metadata name (or another key word, e.g. model) is used as name for an own element in a form. (Might first be implemented in the ODK template? Then in the validator.)
