In passing I've noticed both KoboToolbox and ODK Build generate XForms with type='select1' (when the associated control is a multi-select) and type='select' (when the associated control is a choose-one). But these are not strictly defined data types in either the ODK spec (here) nor as best I can tell data types in the original javaRosa spec (here). Instead, select and select1 are strictly control types (along with input, upload, ...).
No biggie, presumably the javaRosa parser simply interprets both a string when setting the target XML instance element type. But I was curious why these two psuedo-string types were added and why they are not actually in the ODK spec per se, especially since the control type is already specified via the control name associated with the binding used? (the binding doesnt really need to know what specific control widget is actually used for display)
Indeed they are technically "unknown" types and therefore treated as strings (because of what you wrote @xiphware). It seems that rule never got included in the spec. I've opened an issue to add it: https://github.com/opendatakit/xforms-spec/issues/150. Thanks!
does this mean my W3C XForms 'integer' - which isnt a specified ODK data type either - is going to become a 'string'?
Hmm, I'm not sure silently changing unrecognized data types to a default (string) is necessarily the best solution. This is one case I think ODK should in fact barf - there could be weird unintended consequences otherwise, which could be hard to track down... Thoughts anyone?
ODK prescribes 'int' (from here) whereas W3C uses 'integer' (eg here). But mostly its the completely bogus select and select1 datatypes that I'm 'complaining' about.
But I have more to say about select - watch this space....
