Step 1 of 6 in this repo for the survey2ddi retirement. Plan: HANDOVER_SURVEY2DDI.md. No blockers — this is the smallest issue and it gates the deprecation notices in CorrelAid/survey2ddi.
Problem
buildDataCsv shipped in #8, but the CLI cannot reach it. cmdXlsform2ddi in src/cli.ts passes no submissions to buildDdiXml, so:
<caseQnty> is always 0
<fileDscr URI="data.csv"> names a file the CLI never writes
- getting a data CSV requires writing TypeScript against the library
The Python kobo2ddi transform does both halves in one command. Until the CLI does too, nothing in survey2ddi can be deprecated.
What to add
formtransform xlsform2ddi form.xlsx -o codebook.xml --data responses.csv
# writes codebook.xml + data.csv (caseQnty = row count)
--data <path> — response records. Accept both shapes: a flat CSV (header row of question names) and Kobo's submissions JSON array (kobo2ddi pull writes submissions.json). Detect by extension, fall back to sniffing the first non-whitespace byte for [/{.
--data-out <path> — default: data.csv beside the XML output, matching the datasetFilename recorded in <fileDscr>. If --dataset-filename is also given, the default follows it, so the XML and the file on disk cannot disagree.
- Wire the parsed records into
buildDdiXml's submissions option so <caseQnty> is correct, and into buildDataCsv(extractVariables(...), submissions) for the CSV.
- Writing to stdout: with
--data and no -o, the XML goes to stdout and the CSV needs an explicit --data-out — erroring on that combination is fine, silently dropping the CSV is not.
Notes
select_multiple values are expected space-joined; that is what both Kobo exports produce and what buildDataCsv parses.
- Submission keys may be bare question names or
group/name paths — readCell in src/pipelines/xlsform2ddi/data.ts already accepts either.
lstsv2ddi needs the same flag, but its response keying is a separate port — see the LimeSurvey response-normalization issue.
Acceptance criteria
Step 1 of 6 in this repo for the survey2ddi retirement. Plan:
HANDOVER_SURVEY2DDI.md. No blockers — this is the smallest issue and it gates the deprecation notices inCorrelAid/survey2ddi.Problem
buildDataCsvshipped in #8, but the CLI cannot reach it.cmdXlsform2ddiinsrc/cli.tspasses nosubmissionstobuildDdiXml, so:<caseQnty>is always0<fileDscr URI="data.csv">names a file the CLI never writesThe Python
kobo2ddi transformdoes both halves in one command. Until the CLI does too, nothing in survey2ddi can be deprecated.What to add
formtransform xlsform2ddi form.xlsx -o codebook.xml --data responses.csv # writes codebook.xml + data.csv (caseQnty = row count)--data <path>— response records. Accept both shapes: a flat CSV (header row of question names) and Kobo's submissions JSON array (kobo2ddi pullwritessubmissions.json). Detect by extension, fall back to sniffing the first non-whitespace byte for[/{.--data-out <path>— default:data.csvbeside the XML output, matching thedatasetFilenamerecorded in<fileDscr>. If--dataset-filenameis also given, the default follows it, so the XML and the file on disk cannot disagree.buildDdiXml'ssubmissionsoption so<caseQnty>is correct, and intobuildDataCsv(extractVariables(...), submissions)for the CSV.--dataand no-o, the XML goes to stdout and the CSV needs an explicit--data-out— erroring on that combination is fine, silently dropping the CSV is not.Notes
select_multiplevalues are expected space-joined; that is what both Kobo exports produce and whatbuildDataCsvparses.group/namepaths —readCellinsrc/pipelines/xlsform2ddi/data.tsalready accepts either.lstsv2ddineeds the same flag, but its response keying is a separate port — see the LimeSurvey response-normalization issue.Acceptance criteria
--dataaccepts a flat CSV and a Kobo submissions JSON array<caseQnty>equals the record count<fileDscr URI>/<fileName><var name="">order in the emitted XML (already guaranteed bybuildDataCsv— assert it in a CLI-level test)--helpdocuments both new flags