Can `resource.data` be more strict allowing only array of objects?

[roll]

What Data Package version are you using?

v2

Describe the Issue

I think so-called tabular inline data doesn't need to provide too much freedom. Currently, it's both array of arrays and array of objects but inline data is not meant for big data etc so sticken to standard JSON Schema compatible array of objects would make sense and reduce cognitive load.

In general, resource.data should better define it's relation to Dialect spec. Does it support multiline header etc. If we simplify the structure, it will reduce amount of questions like this from implementers. The best case scenario, in my opinion, if resource.data doesn't rely on Dialect at all (it will require fieldsMatch to be at least subset to avoid field ordering uncertaininty).

Technically, this change will require a backward-compatability note to support array of arrays anyway (unfortunately) but at least we can simplify it for newer data packages.

Note

Array of object is Json Schema compatible structure so theoretically it will be possible to define data validation rules in an extension profile via pure Json Schema (for super compact Data Package extensions).

Participation

• [x] I am willing to submit a pull request for this issue.