Add new list field type for typed collections, lexically delimiter-based

[roll]

• fixes Future possibility for delimiter-separated list for arrays (instead of JSON array)? datapackage#736
• fixes Add itemType constraint to array type datapackage#409

---

Rationale

Since the last major Data Package release, there have been two very often occurring feature requests (on the specs and implementation levels):

• ability to have strongly-typed arrays for SQL-interop
• ability to serialize arrays with delimiter instead of verbose JSON serialization

The initial attempt was to implement it as a part of the array type (#31, #34) but during the discussions we figured out that it might be better to separate two groups of data types:

• based on JSON data model (array and object), especially now when we're adding constriants.jsonSchema for them
• based on SQL-array data model (list)

I think we still can merge array and list in this PR but I'm curious what you think as it seems to be that array and list in this PR edition are pretty different both lexically and logically.

[nichtich]

Looks good, just two minor comments!

[nichtich]

Allowed constraints for list should also be mentioned in the text, no?

[roll]

I think it's something to improve on the next maintenance-level iteration. Currenlty, constraint applicability are listed in the constraints section for all the types - https://datapackage.org/specifications/table-schema/#constraints - but I really think it needs to be improved

[cloudflare-pages]

Deploying with    Cloudflare Pages

Latest commit:	3c2a9b4
Status:	✅  Deploy successful!
Preview URL:	https://d9ed3024.datapackage.pages.dev
Branch Preview URL:	https://736-list-field-type.datapackage.pages.dev

View logs

[peterdesmet]

Suggested change

- **itemType**: specifies the list item type in terms of existent Table Schema types. If present, it `MUST` be one of `string`, `integer`, `boolean`, `number`, `datetme`, `date`, and `time`. If not present, the default is `string`. A data consumer `MUST` process list items as it were individual values of the corresponding data type. Note, that on lexical level only default formats are supported, for example, for a list with `itemType` set to `date`, items have to be in default form for dates i.e. `yyyy-mm-dd`.

- **itemType**: specifies the list item type in terms of existent Table Schema types. If present, it `MUST` be one of `string`, `integer`, `boolean`, `number`, `datetime`, `date`, and `time`. If not present, the default is `string`. A data consumer `SHOULD` process list items as it were individual values of the corresponding data type. Note, that on lexical level only default formats are supported, for example, for a list with `itemType` set to `date`, items have to be in default form for dates i.e. `yyyy-mm-dd`.

Typo correction.

Just as with delimiter I think data consumers should have the option not to process this field. Therefore SHOULD.

[peterdesmet]

I think I prefer a separate data type for this, it will make consumption/validation easier. Intuitively, I would call it array, but that is already is already reserved for JSON arrays.

I have updated MUST to SHOULD, to allow consumers to opt to not parse the delimiter and values.

[roll]

@peterdesmet
I think MUST there is better because on a logical (Table Schema) level, it can't be anything else other than a sequence of typed items. How an implementation is going to represent this logical entity -- depends on the implementation. Similar to any other feature we use MUST for implementation that can support this feature but an implementation can just mark array and list as not supported at all (raise error, document etc)

PS.
As previously discussed, for example, fields.missingValues MUST ... but if frictionless-r just doesn't support this feature this MUST is not applicable until the feature is supported.

[roll]

ACCEPTED by WG (6/9)