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

Require more stringent backward compatibility for resource.type #1123

@peterdesmet

Description

@peterdesmet

What Data Package version are you using?

v2

Describe the Issue

Data Package v2 has the following backwards compatibility note for resource type:

If a resource has profile property that equals to tabular-data-resource or https://specs.frictionlessdata.io/schemas/tabular-data-resource.json, an implementation MUST treat it as type property were set to table

In my opinion that is not sufficient. "profile": "tabular-data-resource" implies a v1 Tabular Data Resource, which has more requirements:

property requirement implications on note
profile required Implied
profile must be tabular-data-resource I think we should drop https://specs.frictionlessdata.io/schemas/tabular-data-resource.json as that was never a spec-defined approach
schema required Mention this
schema must follow Table Schema Implied when referring to schema
data must be JSON tabular data The rules slightly different than what is currently defined for inline data, but not sure we should mention that
path "Be a CSV file" Mention this (e.g. as mediatype). Note however that "must be a CSV file" contradicts the beginning of the spec, which says "specialized for describing tabular data like CSV files or spreadsheets."

Update note

I think the backwards compatibility note could be rephrased to:

If a resource has a profile property that equals tabular-data-resource, an implementation MUST treat it as a resource where type is set to table, schema is defined, and mediatype is set to text/csv for files provided in path.

Good old Tabular Data Resource

I like the stringent approach of Tabular Data Resource: it is easier to implement for. Data Package v2 offers more flexibility in "type": "table": it can describe any tabular format and schema is not required. Would it help to bring back a more stringent implementation as a new value for type (in addition to "table")? For example "type": "csv"` explicitly expects:

  • schema MUST be present
  • path MUST be present
  • mediatype MUST be "text/csv"

Ping @roll @pierrecamilleri

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