roll
roll
DQS has a little bit different nature than specs we have now. But for Frictionless Data project in overall I suppose it could be pretty logical move.
I would even make it stricter having `InF/Nan` disabled by default with an option (instead of the constraint) like: ``` number.
@iSnow @lwinfree It is one of the confusing parts in the connection between the specs and the implementations. The idea behind this decision is that this JSON schema has to...
> I don't quite understand the stipulation that the schema is to be applied after those steps I think the point was to validate a schema also because it can...
Sure regarding validation but I have another question - will it still be an indicator of a resource type? (tabular or not). If yes, how to handle it (checking equality...
I think `itemType` should be as simple as possible thing. I would move all the complexity to something like #410 and v2 of the specs
@rufuspollock I think there are two options ## Simple > https://specs.frictionlessdata.io/table-schema/#array ``` array The field contains data that is a valid JSON format arrays. ``` Because it's a JSON we...
> But then, we would need also `itemConstraints`, `itemFormat`, `itemDecimalChar` and there's no end to this. Yea exactly, without all the options a Table Schema type is partially useless. >...
@peterdesmet I had to fix it for Fiscal Data Package shipped with Frictionless. I think it needs to be fixed in the specs too