Table Dialect specification

[roll]

• fixes Table Dialect Spec datapackage#697
• fixes Multi-line header rows datapackage#681
• fixes Support ignoreRows for TabularResource datapackage#344

[cloudflare-workers-and-pages]

Deploying datapackage with    Cloudflare Pages

Latest commit:	698f64b
Status:	✅  Deploy successful!
Preview URL:	https://75bde7b4.datapackage.pages.dev
Branch Preview URL:	https://697-table-dialect.datapackage.pages.dev

View logs

[nichtich]

I object the apparent renaming of established CSV Dialect to Table Dialect and the kind of referencing CSV Dialect like an outdated specification, but this may be based on misreading and can be changed later on.

[roll]

@nichtich
That's basically a new specification so I would not call it renaming. I'll update the wording regarding CSV Dialect

[roll]

Hi @peterdesmet,

can you please take a look at this one as well?

[roll]

@pschumm
@khusmann
@pwalsh
Hi, can you please review? That is the last proposal that would be great to include to the draft release on April 1 🚀

[roll]

Probably it's easier to use a preview version - https://697-table-dialect.datapackage.pages.dev/specifications/table-dialect/

[peterdesmet]

I noticed all CSV Dialect properties are included in Table Dialect, except for caseSensitiveHeader and csvddfVersion. Why is that?

[roll]

@peterdesmet
I think in the context of Data Package (v1) caseSensetiveHeader had no real sense as it was kinda a validation option and didn't really belong to the dialect. As of now, we have schema.fieldsMatch it seems to be this option makes sense again regarding the name-based matching. I'll add it now

Related to csvddfVersion -- we're changing the versioning model so probably this one is not needed but because Data Package descriptors are open regarding custom properties not mentioning it in Table Dialect still make it 100% valid to have

[roll]

@peterdesmet
I dived deeper in the caseSensetiveHeader property and it seems kinda problematic one:

• it defaults to case insensitive headers
• it has never been implemented in frictionless-py, especially with this default
• so in frictionless-py, the header is always case sensitive (which I think is expected behavior for majority of people)

How does it work in frictionless-r? WDYT we're better to do with it?

[peterdesmet]

caseSensitiveHeader is ignored in frictionless-r. I agree that default false is confusing. My take would be to drop this property altogether and only add it when there are use cases.

[roll]

Thanks, I've updated the note

[roll]

ACCEPTED by WG (7/9)