Thanks very much for these, @martijnr. I have a few follow-up questions and comments.
This is not something Collect currently supports but it could. It feels like the API should make it possible to transmit the logo image, then. OpenRosa spec proposal: add optional /client-settings endpoint currently does not do that.
In Enketo, are finalized forms uneditable? Strangely, in Collect, finalized forms are still editable unless they are encrypted. That aside, I think this is equivalent to a combination of default_completed set to true (the default) and admin/mark_as_finalized set to false.
I think this is the same as Collect's constraint_behavior "on_swipe" vs "on_finalize". It only has to do with constraints, right?
Let's say you have validate page set to true. Having validate continuously set to false would delay validation until changing pages but setting it to true would mean that constraint checking would happen on the fly within that page? In Collect, there is no such option and constraint checking always happens on the fly within a page. I think it would be quite hard to block that but I'd have to think more about it.
This is similar to Collect's navigation. That setting has three options: swipe, buttons and swipe_buttons. It sounds like Enketo's is binary. If swipe is enabled, are buttons/links also displayed? Would you consider having three options?
When you say "clear the value", do you mean the contents of an element or removing the irrelevant elements? Is this just about when the pruning happens or does it change what the submission content is?
This is probably not something that would ever be relevant to Collect.
This is mostly to specify custom widgets, is that right? Again, it doesn't seem relevant to Collect. It seems like custom widgets would inevitably be pretty client-specific so if we're going to put this in the standard, I think it should probably be enketo_widgets. Would this require shipping some files?
Collect currently supports additional layers as a single mbtiles file. Adding support for specifying a tileJSON file should be possible. We'd have to think about how it interacts with the other map settings.
Sigh. This is because of our friend Aggregate. Collect has no such setting and it has to be specified at the form level as documented at https://docs.opendatakit.org/aggregate-field-length/#id1. It could become a Collect setting as well.
This isn't supported by Collect but could/should be. I think it'd be good to make this an addition to the core spec.
This isn't supported by Collect but could be.
Does this also set the Enketo interface language or just the form language? Collect currently does not have such a setting. Form language is selected while filling out a form. I'm not sure whether setting this at the client level for all available forms really makes sense. How are users using this in Enketo, @martijnr? Why do they want to override the form definition default for a whole server?
These feel like they are more about where the form is launched from. That is, I imagine go_to is useful when some other web app launches Enketo forms for specific edits. Similarly, an external app might want to launch Collect and have it open to a certain question. That's useful functionality but doesn't feel like it goes with the others. In Enketo's case, the web app in question is probably the same as the OpenRosa server that would supply settings but in Collect's case I don't think they would be the same.