KoboToolbox Compiler

[Ahmad6694]

Hi KoboToolbox Community,

I’m excited to introduce to you an app that i’ve built, the KoboToolbox Compiler, a Shiny app designed to help users validate and detect advanced logical and coding issues within the kobo tool,

So its worth to keep in mind that its working along side with the official ODK validator which means after you validate the kobo tool using the official validator you can upload your kobo tool here to get more and advanced error detection.

Feel free to use it and i would love to hear your valuable feedback.

https://ahmad-shehadeh.shinyapps.io/KoboToolbox-compiler/

[Kal_Lam]

Welcome back to the community, @Ahmad6694! I get this when trying to validate …

[Ahmad6694]

Hello dear, did you validate it using the official ODK validator?

[Kal_Lam]

@Ahmad6694, yes! When validating it with the online validator I get no issues:

[Ahmad6694]

Could you send me the kobotool that you used it here?

[Kal_Lam]

@Ahmad6694, I tested the XLSForm from this community post:

Dynamic choice list in select_one_from_file based on total selection in previous repeat cycle

Understood. You want the user to be able to enter some details immediately upon their selection, but then also permit them to add further details later (for each selected). Have a look at my following form; I think it accomplishes your need. It is quite a bit trickier than the basic select_multiple. You can ignore the choice_filter initially, as that doesn’t fundamentally affect the workflow itself. However, I think it is probably desired to prevent the user from re-selecting previously select…

[Ahmad6694]

Hello again yes please add a (relevant, constraint) columns even if they don’t have value inside of it, because the compiler is using them to detect the advanced check based on them.

[dianedetoeuf]

Hello @Ahmad6694, this tool seems fantastic!! Thank you so much for building it.

Can we make a few suggestions?

I have “contains invalid character in the name column” for all the labels of end_group and end_repeat, while normally there is no need for labels on end groups. Maybe this doesn’t need to be flagged?

I also have the “contains invalid character in the name column” for label of choices that are numbers The form works well with numbers in choices values, so I’m not sure why these would be invalid.

I’m attaching the form I’ve used to test, in case it can be helpful.

Thank you again !
BNS_household_20241212.xlsx (221.3 KB)

[Xiphware]

@dianedetoeuf

I have “contains invalid character in the name column” for all the labels of end_group and end_repeat, while normally there is no need for labels on end groups

Correct. Strictly speaking you dont need to put a label on the end_group or end_repeat; you cannot overlap and groups and/or repeats, so pyxform can reliably associate the next end_group (or end_repeat) it sees when parsing your form with the last begin_group (or begin_repeat) that it came across. So no name is actually needed to match them up correctly.

Indeed, the XLSForm spec specifically states:

… Notice how end group doesn’t require a name or label, because it is hidden in the form.

Labeling your end_group appropriately may help others who happen to read your form to line things up, but it’s not strictly required.

[Ahmad6694]

Hello @dianedetoeuf,
Thank you! I’m glad you liked the Kobo Toolbox Compiler.

Regarding your comments:

1. Yes, the tool can be uploaded and function correctly without the name value in end_repeat questions. However, if there are nested repeats, understanding the loop structure becomes challenging without the name, as it helps users or the people who will do the data cleaning and analysis navigate loops more easily.

2. As a best practice, variable names should not start with a number. In KoboToolbox, this can cause issues when exporting data, as many tools like R and SQL do not handle column names starting with numbers well. It can also lead to parsing errors, incorrect data interpretation, and complications in coding when working with different programming languages.

It’s worth mentioning that not all the errors flagged by the compiler are strictly related to real-time data collection. Some may stem from structural issues in the survey design, or complications that could arise during data cleaning and analysis. Identifying these early helps prevent downstream errors and ensures smoother processing and interpretation of collected data.

Let me know if you have any further thoughts!