Should type=text, type=calculate, and type=hidden be aliases?

[MartijnR]

Since we introduced calculations as default values, and allowed all question types to have no label and no hint, there is some unclarity of the differences between types calculate, text, and hidden in XLSForm. From an XForms perspective these are all the same, in XLSForm there are subtle differences that I think are mostly unintentional historical leftovers. I'm wondering if we should revisit this. I found these differences but there are likely more:

1. type=calculate allows a dynamic default but not a static default
2. type=calculate seems to be doing some different expression validation processing from type=hidden and type=text, see #507
3. type=calculate does not accept an empty value for both calculation and default columns

Though the 3rd point is somewhat useful, I don't think it's a sufficient argument for the existence of type=calculate.

Moreover, the name 'calculate' is not great anymore (for new XLSForm users) after the changes mentioned above. Type=hidden is more sensible, but since we can now hide any question type by simply omitting the label and hint, it has also become obsolete.

So I'm proposing to treat type=calculate and type=hidden as aliases of type=text in pyxform, and stop promoting the use of type=calculate and type=hidden.

What do you think? Did I perhaps miss some important differences between the types that benefit users?

[lognaturel]

I think you're right that switching to implementations to aliases would help reduce redundancy and make things more consistent. I can't think of differences in the types that need to be maintained but will keep pondering.

does not accept an empty value for both calculation and default columns

I would advocate for this being the case for the new combined type. In my experience this helps catch common errors.

stop promoting the use of type=calculate

This I'm pretty strongly against. There are so many examples with calculate and I think it would be confusing for users who primarily pattern match for the documentation to change. For advanced users, thinking through what type they want their calculation to be stored as or falling back to text is not a big deal and certainly we can describe and recommend it. But for a lot of users that adds cognitive overhead with minimal benefit. I think if we were starting from scratch we might go a different way but given calculate has such a long history I think it would be a user-hostile change. Even for advanced users, I think there's benefit from being able to scan the type column and tell that a field is intended to only hold the result of a calculation. In my own form design, I've continued using calculate for that reason.

I don't mind deprecating hidden since it's not broadly in use.