Compatibility with SurveyCTO and ODK

Joripo was built so that a SurveyCTO workbook deploys unchanged. Joripo compiles SurveyCTO's dialect itself, without converting it to ODK's first, so columns such as relevance, label:English, constraint message, read only and text audit, datasets as choice lists, and SurveyCTO's functions are read as SurveyCTO reads them. Real SurveyCTO instruments from live projects are Joripo's compatibility baseline, and real SurveyCTO submissions have been replayed through Joripo and compared with SurveyCTO's own exports cell by cell.

Where Joripo's runtime and SurveyCTO agree, and ODK Collect does not

Joripo's own form runtime (the tester, web forms and Joripo Collect) follows SurveyCTO. ODK Collect runs a different engine, and only understands what a standard XForm can say. On ODK Collect:

• functions only Joripo's runtime implements cannot run, so ODK Collect refuses to open a form that uses one. The upload names each such function; the function reference marks them all;
• a calculate_here is worked out when its group becomes relevant rather than exactly where the enumerator reaches it. A calculate_here that no group gates is evaluated when the form opens (correct for a form-start timer, wrong for a section timer), and several that share one gate record the same moment. The upload reports both cases; the fix is to put each one inside the group it times;
• a calculated default (a calculation on a question the enumerator may edit) is not given: ODK Collect reads the XForm alone;
• field plug-ins do not run;
• the search() appearance lists every matching row of the file, without the fixed choices from the choices sheet;
• the case ID is always blank: ODK Collect has no case management screen.

For the full experience, use Joripo Collect; ODK Collect remains fully supported for the standard parts of a form.

Differences from SurveyCTO itself

• No drafts of forms. Every successful upload deploys. SurveyCTO can keep an upload as a draft until you deploy it.
• Form encryption. A workbook whose settings sheet sets public_key (SurveyCTO's end-to-end encryption) is refused: Joripo does not yet encrypt submissions with a form's public key, and deploying such a form would store respondent data in the clear while its author believed it was encrypted. The server's own encryption at rest is separate.
• hash() uses SHA-256. SurveyCTO does not document its algorithm, so hashed values differ from SurveyCTO's, though matching within Joripo works.
• Seeded randomization uses SurveyCTO's documented algorithm; whether the seeded order matches SurveyCTO's exactly has not been compared against a live SurveyCTO server.
• Generated names. A row with a type but no name (a note used as a heading) is given one, as SurveyCTO does; the two number from different bases, so the generated column name differs.
• Names used twice. SurveyCTO refuses a field or group name used more than once unless its legacy option allows it. Joripo refuses two groups or repeat groups of one name anywhere, and a data field used twice, because the exported data has one column per name; a note named again in another group is accepted, and a ${name} that could mean either is refused as ambiguous.
• Sensors and speed violations. Types that depend on SurveyCTO Collect's sensors are accepted and collect nothing; see Question types.
• Plug-in console. The tester's inspector shows a plug-in's information, parameters and errors; SurveyCTO's live editing of plug-in code is not built.

Refused at upload

A workbook is refused, with the sheet, row and column, when it has a type Joripo does not know, an expression it cannot read, a dependency loop between calculations and relevance (other than the "ask once" pattern SurveyCTO allows), a malformed search(), a public_key, or a form its own engine could not open. Nothing already live changes when an upload is refused.

HTML in labels

Formatting in labels (<b>, <i>, coloured spans) is kept and drawn as formatting, as in SurveyCTO. Joripo does not strip it.