Relequestual
commented
1 year ago This is actually super useful, so thanks. I think there are a few things missing...
- Code generation, specifically "models" or classes, which is a really common use case, and "types" for typed languages
- UI generation, mostly generating forms or other UI elements, which are pretty common. (Some impelementations have larger followings than we do... at least I think)
- Documentation generation - I've seen at least 3 articles talk about JSON Schema primerily for generating documentation. I don't see that covered in your doc
Given how frequently I see these things, I'd expect them to be explicitly called out.
You mention database constraints in section 3.7. Can you explain why this is in section 3 as opposed to a note in section 4, aka a use case for extensions.
Given this work, maybe you could propose a short bulleted list of what's "in scope" for our charter work? 👉 https://github.com/json-schema-org/community/discussions/286#discussioncomment-4391250
awwright
This is a document I've been working on for a little bit that I think would be very relevant to some of the discussion right now.
We're trying to figure out what parts of the specification are "stable," but (IMO) stability is something that you determine with respect to a particular use case. An example I pointed out earlier, if I publish a GPU-intensive program that stops being effective as a space heater because I improved the algorithm, too bad for you because it was never "stable" for home heating purposes, only cat detection purposes (or whatever).
This document would describe the use cases that we actually intend to support; when we make changes to the specification, we can point to this document and say "this feature in Use Cases would break if we made this change." Or we can make a change and point at this to say "yes, the change breaks cat detection, but JSON Schema was never intended to perform image analysis."
Here's a PDF rendering (note how it's not a "draft"): jsonschema-use-cases.pdf
While it currently specifies applications as "Use Cases," a "Requirements" section would be expanded to actually list the particular methods that implement each use case.