Clarify how whitespace should be treated in secondary instance property names and values

[lognaturel]

This currently varies by implementation. Notably, Enketo strips whitespace from CSV column header names.

I think we should preserve values exactly and reject files with leading/trailing whitespace in property names.

The spec phrasing would be:

• for CSV: Column names MUST NOT contain leading or trailing whitespace.
• for geojson: Members of properties MUST NOT contain leading or trailing whitespace in their names.
• values: Processors MUST preserve whitespace in values exactly as represented in the source document.

[lognaturel]

@seadowg @garethbowen this has come up again as an issue on the forum (getodk/web-forms#818) and it would be great to clarify and make Collect and Web Forms consistent.

Currently Collect happens to crash when a CSV/geojson file is used as an itemset source and the ref specified for value and/or label has a space in it. I think we should specifically check for spaces when first parsing the CSV and refuse to load the form if any column at all has a space in it. I said leading or trailing but really I think we should fail when there's a space anywhere.

Making those changes won't result in the issue being caught at form design time because external files are not currently validated then. We could additionally have Central do that validation at file attachment time.

[seadowg]

@lognaturel could you add an example CSV and geojson file for clarity here?

[lognaturel]

JavaRosa tests with example files: getodk/javarosa#853

[seadowg]

• for CSV: Column names MUST NOT contain leading or trailing whitespace.
• for geojson: Members of properties MUST NOT contain leading or trailing whitespace in their names.
• values: Processors MUST preserve whitespace in values exactly as represented in the source document.

I can't think of any problems that these rules would create, and they seem to protect against the issues you mention.