Open ukanga opened 6 years ago
Seems we will use the flow-spec for this.
@markboots from your example package in this issue, I see that you have the questions
as a list of objects yet the definition in the specification.md states that it should be an object.
"The schema property must additionally contain a questions object describing metadata for all the Questions pertaining to Responses in this package. ..."
Has this definition changed? Are we supposed to support both or only one of them?
Discussed on call 2018-03-01:
Preference of @ukanga is that it's a list, so there is a specified order. (e.g.: this question comes before the next question).
Proposal: switch the spec to use a list for the questions in the schema (consistent the example).
@nditada , would you be able work with that change?
For testing purposes with Ona right now: current implementation uses an object... so irrespective of this decision, current testing with Ona should use objects for questions.
I'll take this one on behalf of @nditada.
Preference of @ukanga is that it's a list, so there is a specified order. (e.g.: this question comes before the next question).
TL;DR: We'd suggest to leave it as an object.
Reasons:
order
attribute somewhere which lists question ids in order if it is meaningful, or is null
otherwise. The aggregator can then respect the received order when it holds a value or confidently apply any order (e.g.: sort lexicographically by id or name) when it's null
.I went with supporting both since from recent conversations it seems the initial testers had this as a list instead of as an object. https://github.com/onaio/floip-py/pull/7.
With regards to picking the order from the ROW_ID I suppose with the current implementation of Ona platform this will be lost.
Going to close this and hope this is something that is clear in the Flow spec and not necessarily required for the Flow Results spec.
Hi @ukanga , thanks for being flexible and supporting both :)
It would be great to confirm with you guys how we should leave the spec, as there is some ambiguity in the examples right now.
If we stay with object, I think that's clear.
If we go with a list... How did you implement the list @ukanga ?
Option A) From an (possibly incorrect) example in the API spec:
"questions":[
{
"1448506769745_42":{
"type":"select_one",
"label":"Are you a woman or a man?",
"type_options":{
"choices":[
"Woman",
"Man",
"Other"
]
}
}
},
{
"1448506773018_89":{
"type":"numeric",
"label":"How old are you? Please enter your age in years.",
"type_options":{
"range":[
-99,
99
]
}
}
}, ...
Option B) More logical:
"questions":[
{ "id":"ae54d3",
"type":"multiple_choice",
"label":"Are you male or female?",
"type_options":{
"choices":[
"male",
"female",
"not identified"
]
}
},
{ "id":"ae54d7",
"type":"multiple_choice",
"label":"Favorite ice cream flavor?",
"type_options":{
"choices":[
"chocolate",
"vanilla",
"strawberry"
]
}
},...
Votes for:
z) Leaving spec as object. (Vote of InSTEDD based on above) a) Option A above b) Option B above
?
Currently, the
questions
property uses an object/dictionary with the questions in the flow results. When generating an XForm out of this, the order of questions can be important since there is a possibility of also collecting data through the XForm. Iterating through thequestions
objects does vary with environment, in my case between python 2.7 and python 3.6, should we have a way to specify the order? Or possibly switch fromquestions
being an object to a list of objects, similar to thefields
property.