Replies: 5 comments
-
@Deiz this makes good sense. Generally we should not fail on an optional or even recommended field but just issue warnings. This is almost a separate recommendation about how validators work against the schema. |
Beta Was this translation helpful? Give feedback.
-
@Deiz as someone implementing libraries to support Data Package and JSON Table Schema: I see the problem that you are trying to solve, but it seems to me incredibly difficult to solve in a reasonable way. Two examples you gave:
So, my point is: we might try to provide some hinting system for ranking errors, but is this something that we can truly abstract meaningfully? |
Beta Was this translation helpful? Give feedback.
-
@rgrp @danfowler any comments on this? My opinion is still the same as the above comment. I think if we are not acting on this, we can close the issue. |
Beta Was this translation helpful? Give feedback.
-
@pwalsh this seems to me like notes for implementors - making me think we do need a patterns or primer section for this kind of thing. We sort of have this here already: http://data.okfn.org/doc/publish-faq. I am going to label this as such now and will raise and issue generally about the FAQ / Patterns / Best Practice stuff. |
Beta Was this translation helpful? Give feedback.
-
@rgrp +1 |
Beta Was this translation helpful? Give feedback.
-
From a recent scan of GitHub data packages, roughly 67% validate successfully against the current data-package.json schema.
Due to the pass-fail nature of the validation, it's not readily apparent whether a package is wholly out of compliance (e.g. missing name field) or failed for a minor reason (e.g. specified an invalid media type for one of its resources). I propose assigning a severity to each issue, depending on both the language in the spec and the nature of JSON.
My proposal is to rank issues by the language involved (MUST being highest-severity) as well as whether the issue occurs under an optional parent. As an example, a missing top-level name field would be critical severity, while violating a MUST under a SHOULD would be at most medium severity (e.g. an invalid hash on a particular resource).
Here's a quick table to illustrate what I'm describing:
It might also be useful to include a warning level, for when an explicit recommendation given by a SHOULD is disregarded, e.g. omitting a name field on a resource, although many SHOULD directives appear difficult to enforce in an automated manner.
Beta Was this translation helpful? Give feedback.
All reactions