Errno Expecting value:3 (unable to deploy)

User Support Form Building
1

@Kal_Lam I am getting this strange while deploying my form. It works fine when I test it with XLSform Online. I have tried fixing it in vain. What c
Copy of Day_care_mapping_tool (002).xlsx (125.2 KB)
ould be the issue.

image
image793×370 16.6 KB

See the tool.
Alex

2

@AlexRutto77, I observed that you use the name model under the survey tab at row 41. I changed it to model1 and it worked.

image

Please be informed that the name model is already booked by the system. Hence, you will need to be careful when using the same in the upcoming days.

Your fixed XLSForm:

Copy of Day_care_mapping_tool (002).xlsx (121.1 KB)

3

Dear @Kal_Lam, @Josh, and @Xiphware,
It is about ten times this “model” problem was reported here (search : name model). I would like to suggest

It would also be great to have a commented list of typical ERRORs for the community, like

  • expecting value: 3,
  • unable to deploy Expecting value: line 2 column 1 (char 1)
  • allow_choice_duplicates
  • error: 502 Bad Gateway
  • Server Error (500)
  • 504 Server Error: Gateway
    and others which are discussed here often and not easy to understand.
2 Likes
4

Thank you @wroos. We have actually planned to document these in a new article.

1 Like
5

Great to hear @Kal_Lam ,
Especially helpful might be:

Who can promote this?
Kind regards

6

@wroos, please be informed that we will be only documenting an article that will guide users to build an error free XLSform. The ODK Validator aspect is dealt by ODK team.

1 Like
7

Much appreciated. This works.
Alex.

2 Likes
8

This actually sounds like a possible bug in KoBo, possibly related to how KoBo is parsing the XForm instance XML hierarchy, which defines its own model element. But I’m not aware of anything in the XForms spec that precludes having a group with a label ‘model’, an observation reinforced by fact that XLSForm Online happily parses it and Enketo happily runs it.

In order that this doesn’t fall-thru-the-cracks I might suggest opening a GitHub Issue (against kobocat?) to ensure someone in the KoBo dev team looks into it further. Suffice to say, unless the form fails to run under KoboCollect/ODK Collect, then I dont think any change to ODK Validator is probably warranted; the form definition itself appears to be XForm-spec conformant, which is what ODK Validator is validating [sic].

2 Likes