-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new list
field type for typed collections, lexically delimiter-based
#38
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, just two minor comments!
- datetime | ||
- date | ||
- time | ||
constraints: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Allowed constraints for list
should also be mentioned in the text, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Deploying with
|
Latest commit: |
3c2a9b4
|
Status: | ✅ Deploy successful! |
Preview URL: | https://d9ed3024.datapackage.pages.dev |
Branch Preview URL: | https://736-list-field-type.datapackage.pages.dev |
The list field can be customised with these additional properties: | ||
|
||
- **delimiter**: specifies the character sequence which separates lexically represented list items. If not present, the default is `,` (comma). | ||
- **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`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- **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
.
I think I prefer a separate data type for this, it will make consumption/validation easier. Intuitively, I would call it I have updated MUST to SHOULD, to allow consumers to opt to not parse the delimiter and values. |
@peterdesmet PS. |
ACCEPTED by WG (6/9) |
itemType
constraint toarray
type datapackage#409Rationale
Since the last major Data Package release, there have been two very often occurring feature requests (on the specs and implementation levels):
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:array
andobject
), especially now when we're addingconstriants.jsonSchema
for themlist
)I think we still can merge
array
andlist
in this PR but I'm curious what you think as it seems to be thatarray
andlist
in this PR edition are pretty different both lexically and logically.