Context - Form with xml reference to columns in the XLSform choices tab from the calculation column of the survey tab. Form cannot be converted to XML for upload to ODK aggregate or uploaded directly to Kobo or other platforms.
Issue - For forms which include a choice_filter in any earlier or later question, the calculation works well, however if the form makes no use of the choice_filter column or does not include one, then the calculation fails.
Error - Error: ODK Validate Errors:
Something broke the parser. See above for a hint.
Error evaluating field 'region': The problem was located in calculate expression for ${region}
XPath evaluation: Instance referenced by instance(country)/root/item/region does not exist
Caused by: org.javarosa.xpath.XPathMissingInstanceException: The problem was located in calculate expression for ${region}
XPath evaluation: Instance referenced by instance(country)/root/item/region does not exist
Likely cause - It looks like for xlsforms, unless a choice_filter is specified, non-standard columns in the choices tab other than "list_name", "name" and "labels" etc. are ignored.
Workaround - Add to the form a dummy question with a choice filter and a relevancy of 1=2. the question does not need to be related to the calculation with the error and can appear anywhere in the form. The content of the choice_filter is mostly irrelevant.
Suggested solution - Treat columns in the choices tab in the same way regardless if the form includes choice_filter or other non-xml references to these columns or not. This would allow for the inclusion of small sections of xml in forms while maintaining the template in a manageable xlsform.
Hi thanks very much for these links. https://github.com/XLSForm/pyxform/issues/387 in particular looks to be interesting. Do you think its necessary for this behaviour by the parser (adding choices as instances) to be dependent on the inclusion of a choice filter? Would it cause problems for example if the dependency on the choice filter was simply removed?
It would I imagine make some forms slightly larger in their xml forms but possibly there is a more significant reason that I dont see and its not as straightforward as it appears.
Whew, I have lost all concept of time these past few months.
That’s the question I posed in https://github.com/XLSForm/pyxform/issues/203 and I was convinced by the arguments raised in that thread that keeping the separate select types was the way to go.
It would be great to get your thoughts on how you’d expect something like https://github.com/XLSForm/pyxform/issues/176 to work or whether you think it really shouldn’t be a separate construct. We could probably detect extra columns and generate secondary instances if any exist, for example.
Thanks very much for following up on this. From reading the links you referenced I don't find a barrier although I have a limited understanding of the existing code at this point. From the discussion you refer to it looks like columns in the choice sheet which are additional to the mandatory list_name, name and label columns are ignored by default when converting from xls to xml for performance reasons.
In a way this makes sense. I don't think I have ever seen a form with information in additional choices columns that wasn't directly necessary for the functionality of the form but I imagine they do exist. In the discussion, the possibility of including this information in the xml form by default is mentioned as it would be a simplification of the code but I believe that there is an alternative option which would also maintain the current logic.
The alternative would be that the condition for including these choices columns in the xml would be dependent on the form including either a choice_filteror a manually typed xml reference eg. calculation = instance('abc')/root/item[name=${abc}]/def, rather than being dependent only on the inclusion of a choice_filter. While possible to include such a reference in other columns of an xlsform, the calculation column is the key one in this case.
Either solution would I believe work but as I am not familiar enough with the code to know if the second option would add a significant level of complexity to the process of converting to xml format.