Skip to content
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

Non-structural validation #52

Open
gregsdennis opened this issue Jul 9, 2023 · 0 comments
Open

Non-structural validation #52

gregsdennis opened this issue Jul 9, 2023 · 0 comments

Comments

@gregsdennis
Copy link
Member

For non-structural details, many languages support (either through built-in mechanisms or third-party libraries) some way to annotate a type to indicate what range of values are valid for an object's members. In JSON Schema, these are represented with keywords like

  • minimum
  • maxLength
  • multipleOf
  • uniqueItems
  • etc.

However, the way to represent these in language code varies greatly.

Translating these requirements to the language model allows validation logic that's already in the language to be invoked. However it also promotes using that validation logic (which may differ from JSON Schema's intent) over using JSON Schema directly. This may cause disparity between the validations from the language and JSON Schema.

Unless we can ensure that the code annotations provide the same validation that an equivalent JSON Schema would, I'm not convinced including them is a good idea.


Another aspect of this is schemas which have these requirements at the top-level:

{
  "type": "array",
  "items": { /* ... */ },
  "minItems": 4
}

Usually these types of constraints are expressed on object members, not on types. Does it make sense to say that an instance of a array must have at least 4 items, or that a lone integer must be more than 50? (I can see a case for minimum: 0 being used to identify an unsigned integer type, though.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant