Other formats for specification files besides XLS (like YAML?)

Support
1

I believe the ODK specification is specific to XML documents. So, for folks that do not want to edit XML manually the options are XLS Forms or ODK Build (both of which should eventually resolve the data back into XML). I am new to ODK, but am curious to know if other file formats besides XLS have been considered for storing form specifications? What were the pros and cons that have lead to XLS being the de-facto standard?

To me, the structure and layout of large complex forms does not lend itself well to the XLS matrix-style format. Hierarchy and nesting is difficult to parse. Also, changes to XLS binary files are not easy to review via SCMs like Git.

What are some disadvantages that might come through using something like YAML to structure the form specifications instead of XLS?

I assume there is nothing really stopping me from writing specifications in YAML as long as I have a way to convert them to valid ODK XML files in the end. However, since I am new to this ecosystem I wanted to reach out and see what the history was behind the trend towards XLS.

2

FYI ODK Build has its own JSON file format for saving XForm definitions. It looks like this:

{
  "title": "myform",
  "controls": [
    {
      "name": "name",
      "label": {
        "0": "What is your name?"
      },
      "hint": {},
      "defaultValue": "",
      "readOnly": false,
      "required": false,
      "requiredText": {},
      "relevance": "",
      "constraint": "",
      "calculate": "",
      "length": false,
      "invalidText": {},
      "metadata": {},
      "type": "inputText"
    },
    {
      "name": "age",
      "label": {
        "0": "What is your age?"
      },
      "hint": {},
      "defaultValue": "",
      "readOnly": false,
      "required": false,
      "requiredText": {},
      "relevance": "",
      "constraint": "",
      "calculate": "",
      "range": false,
      "invalidText": {},
      "appearance": "Textbox",
      "kind": "Integer",
      "selectRange": {
        "min": "1",
        "max": "10"
      },
      "selectStep": "1",
      "sliderTicks": true,
      "metadata": {},
      "type": "inputNumeric"
    }
  ],
  "metadata": {
    "version": 2,
    "activeLanguages": {
      "0": "English",
      "_counter": 0,
      "_display": "0"
    },
    "optionsPresets": [],
    "htitle": null,
    "instance_name": "",
    "public_key": "",
    "submission_url": ""
  }
}

myform.odkbuild.txt (804 Bytes)

Correct. Other than form creation tools (most of which are based about XLSForms, as you have observed...), the core ODK form submission, data collection logic, etc is based around by the W3C standard XForms definition.

1 Like
3

Bringing this back up because I recently chatted with one of @jkuester's colleagues at Medic and the topic of keeping forms in version control came up again. I mentioned that folks have written different tools to help with this, and in particular I recommended checking out @Sjlver's yxf.

I think there are two main reasons that XLSForm remains so popular:

  • People who need to define forms are often very familiar with spreadsheets so it's a comfortable, portable context that offers just enough structure to make form authoring accessible. With tools like the XLSForm template, the chance of very common errors is reduced. YAML may seem simple but it requires quite a bit of extra rigor when editing by hand. IDEs can be helpful but most people who define forms don't use them as part of their regular work.
  • It's very helpful when authoring complex forms to see both many questions and a lot of information about questions at the same time. A spreadsheet essentially maximizes both dimensions and makes it very easy to customize what you see. For example, people do things like hide all columns except for label and relevance expression at a particular phase of form design.

I'm curious to know what has happened over the last three years, @jkuester -- have you come to love XLSForm? Found alternatives that you prefer?