[inbox] Principles (new and old)

[rufuspollock]

Reducing magic (june 2020)

• Inspiration: http://tech.datopian.com/notebook/#_10-things-i-regret-about-nodejs-by-ryan-dahl-2018-2020-05-17-rufuspollock - especially see video and section where Dahl regrets allowing paths without extensions. Also general point that module resolution should run off urls - we already have a perfectly good locator mechanism
• => profiles use urls to json schemas
• => no name on resource

Parsimony / Simplicty

• Parsimony: => no name on resource

[roll]

Is there a chance that we can reduce the number of properties' mixed types as we discussed previously e.g.

• making schema.primaryKeys an array only
• making schema.foreignKeys.[reference.]fields and array only
• considering another notation for multipart resources as resource.path being string or array is a real pain to handle in software

I think most of the type mixing makes implementations struggle and, at the same time, I'm not sure whether it helps end-users or confuse them even more. E.g. if you see schema.primaryKey as a string in one example and them you see it as an array in another example, you will probably start thinking what the right one or out-dated or etc.

[roll]

Just wanted to share another thinking. I'm wondering if currently, the specs are too fragmented which makes it hard to understand Frictionless Data conceptually.

I think in general we can have 4 core specs (+ numerous extra specs like FDP):

• data package (not sure if tabular data package is needed at all after tabular data resource introduction)
• data resource (I would merge data resource and tabular data resource making it one hierarchical spec)
• table schema
• table dialect / csv dialect (Frictionless Data Community Survey #697)

Also copying @lwinfree as we discussed earlier the specs understanding problem

PS.
Profiles (aka JSONSchema), in this case, will not be 1-to-1 to the specs, it will be 1-to-n. E.g. resource spec will have a few attached profiles (general/tabular).

[lwinfree]

I definitely agree that it is confusing right now. From a technical decision, I'm not sure what is best, but I think either way, we should work to better document the distinction between the various specs to help remove that confusion.

[roll]

Actionable issues:

• Resource name should no longer be required (and need not be slug-friendly) datapackage#685
• Profile is a url rather than string datapackage#689