I am wondering what the “official” spec is regarding the contents of a field’s label and hint. After some reading on https://xlsform.org I still was not exactly sure if a field/group without a label or hint value was technically permitted per the spec. (As I understand it, the <label> element is required, but perhaps it can be empty?)
Based on my experience, Enketo will still render the form, but Pyxform will not convert it (unless the field is a type that does not require a label).
The main use-case we have is for sub-groups that exist for data organization, but do not need a user-facing heading. So we want the fields nested in a hierarchy in the data model, but that grouping should be transparent to the user. Technically this case works with pyxform/Enketo, but we get a warning when converting with pyxform (saying the group does not have a label). I am wondering if there is some proper way to do these organizational groups without getting the warning? If I put the field-list appearance on the group, the warning goes away, but I have always used field-list to designate distinct pages of questions, so it feels a bit weird to have nested field-list groups. Is this expected usage of field-list?
Another use case we have is for fields that should not be shown on the UI but also have no starting value (or calculation) so are not a good fit for calculate fields. (In our case these fields can get programmatically populated with values by our wrapper app.) The behavior of the hidden type works great for this! I see this hidden type documented here: https://xlsform.org/en/#question-types. But, I do not see it on the reference page: https://xlsform.org/en/ref-table/. Is there any plan to remove support for the hidden type from pyxform, or is this something I can recommend our form designers keep using?
XLSForm.org is super useful as a primer on form design but it's not as in-depth as the user facing docs at https://docs.getodk.org and not as technically detailed as the ODK XForms spec. For these kinds of deeper questions you may want to triangulate between the three or ask here as you've done!
Groups without labels can be helpful for organizing questions in a way that's invisible to the user. This technique can be helpful for internal organization of the form. These groups can also be a convenient way to conditionally show certain questions.
The ODK XForms spec explicitly mentions groups without labels:
A combines elements together. If it has a child element, the group is considered a presentation group and will be displayed as a visually distinct group.
This bothers me too -- I've usually made a very deliberate decision not to have labels for certain groups and it's annoying to have all that noise. I think we should consider removing the warning.
Having multiple nested groups with the field-list appearance isn't intended to have any effect. That is, only the outermost group with field-list is supposed to change anything. It's fine to nest multiple but it's not really expected. It's a weird pyxform quirk that it silences that warning. Maybe the logic for that is that pyxform considers groups with the field-list appearance as structural.
For pyxform, fields must have a label, hint, or media label defined with a value. Some ODK XForms form filling clients may render fields without any but it's not tested or recommended.
No plan to remove it, we should add to the reference, thanks.
I cant think of anything off the top of my head. Anybody who will have a problem with groups not having a label is already misbehaving, since its strictly optional [as far as I can tell, KoboToolbox doesn’t have any issue with groups w/o labels - we just substitute the mandatory group name elsewhere if its label is missing]. And the suggested change is just a warning about it anyway.
Granted, unnamed groups may be a bit atypical, but certainly not fatal, and might suggest an innocent (?) mistake on the part of the form writer. So I guess its whether that’s sufficiently alarming to need to raise an explicit warning about it, or just let it fly and thereby reduce the noise…
