Collect: Use something like TriggerWidget when type boolean is specified in form

[lognaturel]

Currently, the way to get a checkbox widget is to use trigger in a form as described here. The result is either blank (false/unchecked) or the string 'OK' (true/checked). The XForms Cookbook here suggests that the intent for trigger is that it be used to represent buttons.

The W3C XForms way of getting a checkbox seems to be using a data type of boolean as described here.

When a form that has a type bind attribute of boolean is read by Collect, the string widget is displayed because WidgetFactory here doesn't specify a particular widget for boolean. Instead, a widget like the existing TriggerWidget should be used and write out either 'true' or 'false' as its value.

I think the trigger approach should be deprecated unless there's some kind of explanation for it. It probably shouldn't actually be removed but it should be replaced in all documentation.

More context in this thread from the ODK developers' mailing list.

[tiritea]

Another possible problem with using a trigger [but one I havent confirmed in Collect, yet...] to effectively 'set' a boolean value, is that if you 'set' your boolean - to true - via the trigger, can you subsequently go back and 'unset' (untrigger?) the boolean back to false? If not then this could be a significant issue, because all the other data types you can revise.

[lognaturel]

@tiritea "Fortunately", I think that the current usage of trigger has nothing to do with the XForms trigger. You can change the boolean back and forth as much as you want.

[tiritea]

I think what you meant to say was "You can 'acknowledge' (or repudiate) back and forth as much as you want" :-) But its probably a good thing for Collect to support for indecisive users... ha

[lognaturel]

@grzesiek2010 To be more explicit, trigger is not meant to be used in this way at all. This is the kind of form that should work: desired-boolean.txt

The resulting instance should look something like:

<?xml version='1.0' ?><data id="desired-boolean"><boolean1>true</boolean1><boolean2>false</boolean2></data>

I said "something like TriggerWidget" because I think we should introduce a better name such as BooleanWidget. Its output should be true or false, never OK. We do need to maintain compatibility, though, so TriggerWidget will have to stay.

@tiritea Does all that sound right?

[tiritea]

FYI as you described is pretty much exactly how I've done it in my XForms client, and I think how booleans were probably intended to be handled in the XForms spec. I so must naturally agree... :-)

[lognaturel]

@tiritea Good to know we're interpreting things the same way!

[grzesiek2010]

@lognaturel ok so to be sure: it should be a new widget (similar to TriggerWidget - with checkbox) and as an answer it should save true/false that's all am I right?

[tiritea]

For reference: https://en.wikibooks.org/wiki/XForms/Checkbox

[grzesiek2010]

@lognaturel

Its output should be true or false, never OK.

If we use DATATYPE_BOOLEAN we use BooleanData to save/read an answer and the asnwer isn't saved as true/false as you said. It's 1 or nothing. So if you want to save true/false values we need changes on the Javarosa side as well.

[lognaturel]

Very interesting. I didn't realize this but true, false, 0 and 1 are all valid literals just to make things more annoying (see W3C standard). I think 0/1 is fine, systems that are XSD-compliant should be able to handle that as well. I have verified that #959 does in fact result in 0/1 and not 1 or blank. @tiritea?

[lognaturel]

Oh, no, I'm looking back at this thread and it seems that Aggregate treats 1 as false. Yikes! I do think we should fix that in Aggregate at some point but perhaps in the mean time the right thing to do is to output true/false for boolean. I don't think that would have any negative impact (other than, of course, we'd need to release a new version of JavaRosa). What do you think, @grzesiek2010?

[tiritea]

0/1 and true/false are probably the most formally correct (and expected) boolean literals. Yes/No seems a bit on the colloquial side IMO, but no big deal; they're legitimate boolean literals in some languages (eg Objective-C). However, 'OK' is (excuse the pun) !OK... :-) The word is too imprecise and ambiguous I think for something as concrete as "TRUE or FALSE (and nothing in-between!)"

And yes, alas, Aggregate will interpret a '1' passed in the XML for a submission, containing an element with a boolean binding type, as false (!).

AFAIK, Aggregate always passes back "true" or "false" in the XML if you fetch a submission containing a boolean element.

[lognaturel]

Unfortunately, I think that all means that this issue has dependencies. I think the easier one to resolve would be to have JR output true and false for boolean. @grzesiek2010 can you please see whether that would affect anything else? If not, you can issue a pull request for that and we can make this all part of the May release.

[tiritea]

FYI my XForms client outputs true or false for boolean. It seems like an obvious choice given that's what ODK Aggregate will give you back.

Keeping "OK" about is probably fine for legacy support, but probably not something to encourage, or overtly document...

[tiritea]

Since ODK Collect will now accept 'type=boolean', it would be appropriate for XLSForm to now accept boolean as a valid binding type. It current throw an "unrecognized type" error - see my earlier comment here).

Would you like me to open an issue at XLSForm, or would one of you guys/gals prefer to do it, for tracking purposes?

[lognaturel]

Issues and pull requests on the XLSForm spec and pyxform repos would be appreciated. You can refer back to this one so it's all connected!

[IanLawrence]

We do need to maintain compatibility, though, so TriggerWidget will have to stay.

Given this then how should/can the original xforms trigger (an abstraction of a web button or another event) be used?. I assume this is not currently possible and will require thought here first?

[lognaturel]

@IanLawrence Unfortunately, I think it would be pretty confusing to use trigger for something else at this point. If you have a specific use case you'd like to see supported, please file another issue and we can explore different options.

[lognaturel]

There's some interesting background at opendatakit/xforms-spec#115. This might not be such a great change to make after all.