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,
select1 are strictly control types (along with
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)
@Alex_Dorey @issa Do you know the answer to Gareth's question? I don't remember how this came to be!
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?
Well, it's been this way for about a decade and this is the first anyone has complained
It's been a while since I looked at all this. Can you remind me again the syntax difference between and ODK integer and the XForms integer?
ODK prescribes 'int' (from here) whereas W3C uses 'integer' (eg here). But mostly its the completely bogus
select1 datatypes that I'm 'complaining' about.
But I have more to say about
select - watch this space....