The second corpus: XForms

The first corpus asked what FormScript cannot say about FHIR. This one asks the same question about a different source language, and it is a probe, not a census: it takes every XForms document in three named directories at three named commits, and reports what the language could and could not carry over. It does not claim to represent every XForm ever written.

The point is generality. A language that can absorb one shape of source is not a language; it is a front end. XForms is a good second shape because it is a form language in its own right — it has its own expression language (XPath 1.0), its own way of saying "ask this only if that", and its own way of saying "compute this".

This report is generated by npm run corpus:xreport, which re-reads every converted document and runs it through the lexer, the parser, the analyzer and the engine before writing a word of it.

The headline

• 166 sources from 4 publishers, covering 4 domains.
• 163 forms converted from 2422 source nodes into 1931 FormScript fields.
• 163 of 163 parse and analyse with no error.
• 163 of 163 evaluate: the engine builds a transaction and produces an output document from each one.
• 0 carry an advisory from the language itself.
• 3 sources rejected outright, with a code.
• 704 gaps were recorded, of which 404 lossy — something the source said that FormScript cannot say.
• 61 of 163 forms lost nothing at all; 102 lost something.

The rejects

The rejects come first, because they are the measurement.

The rejects are XML that came from a form system and turned out not to be an XForm. The shape check says so instead of converting half of it.

The sources

The upstream files are not redistributed. corpus/manifest/xforms-sources.json pins each one by URL and SHA-256; npm run corpus:xfetch reads them again and checks the bytes it gets against the pin.

What the toolchain said

What could not be carried over

Every gap names the XForms location that produced it. A gap is either lossy — something meaningful was dropped — or informational, which records something that does not change what the form means.

The three findings

1. The model holds; the expression language does not. All 163 forms parse, analyse and evaluate. The shape of an XForm — groups, repeats, questions, choices, calculated values, relevance, constraints — maps onto FormScript almost entirely. What does not map is XPath. 131 expressions used something FormScript cannot say: extension functions (uuid, int, regex, household-exists, indexed-repeat), node positions (position(), current()), and predicates. Every one of those is a behaviour the form had.

2. XForms has an instance model; FormScript has a form. An XForm carries a whole tree of data nodes, including nodes the body never shows. FormScript has fields, and a field is something the form shows or computes. 18 nodes across the corpus held a value that had nowhere to go.

3. Options from elsewhere are not options. 141 controls took their options from a secondary instance rather than from the form — how ODK builds cascading and dynamic choice lists. FormScript has optionsFrom for a list fetched from a server, but the list is not in the document, and an XForm carries its list inside itself.

Document by document

Each row is one converted form. The gap codes say what was lost; corpus/reports/xforms-conversion.json has the detail.