XLSForm call a column from choices in the "relevant" field

1. What is the problem? Be very detailed.
The attached example which is a hugely simplified example of what I am trying to do. I want to ask the third question (${university}) "Does the city have a university?" only if the place selected in response to the second question (${place_choice}) is a city. This "city" property I have defined in the choices tab in a column called "type". So what I am trying to work out is whether I can call the "type" column from the response to ${place_choice} in the "relevant" option for ${university}. So for relevant something like selected(${place_choice}, type = 'city').

Or perhaps there is another way of doing this without writing a very long-winded clause in the "relevant" column

relevant_example.xlsx (11.2 KB)

Hi @Paul_Bessell,

No, there is no way of calling that "type".

One solution I would advise is to break the town and city choices, so that each appear differently and use that reponse to check for relevance.

Hi Dickson

Thanks for your reply and your help. It is reassuring to know that I am not missing something simple.


1 Like

Hi @Paul_Bessell,

Thinking of a workaround of your issue, since you already know which place is a city or town, a way to achieve that easily without changing much your design will be to introduce some preloaded data, then getting the type of place.

Checkout the files to see what i mean relevant_example.xlsx (11.1 KB) typedata.csv (147 Bytes)


Hello @dicksonsamwel

Many thanks. This is perfect. Exactly what I was seeking to do.

Best wishes



For completeness, you can use your original form with a relevant expression that looks like:

instance('place')/root/item[name = ${place_choice}]/type = 'city'

This reaches down to the underlying ODK XForms specification with an XPath expression that filters place entries to get the one matching your prior selection and then compares its type to 'city'. XLSForm could hide some of the complexity of building this kind of expression the same way that the ${} syntax does but it doesn't currently do so.