WARNING: THIS SITE IS A MIRROR OF GITHUB.COM / IT CANNOT LOGIN OR REGISTER ACCOUNTS / THE CONTENTS ARE PROVIDED AS-IS / THIS SITE ASSUMES NO RESPONSIBILITY FOR ANY DISPLAYED CONTENT OR LINKS / IF YOU FOUND SOMETHING MAY NOT GOOD FOR EVERYONE, CONTACT ADMIN AT ilovescratch@foxmail.com
Skip to content

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

@roll

Description

@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

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    Projects

    Status

    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions