3 ms·

Those are certainly words, but since the words they use to describe what differentiates them form JSON Schema is just asserting that their thing is for exactly

Those are certainly words, but since the words they use to describe what differentiates them form JSON Schema is just asserting that their thing is for exactly what has always motivated schema languages including, but not limited to, JSON Schema, and since JSON Schema supports that purpose far better, I am left confused At best, I can guess that maybe they are trying to get at the fact that JSON schema supports some structures that can be awkward or unidiomatic for data models in some languages (a lot of what you can do via allOf or oneOf fits this) and they want to narrow down to something where what can be defined in the schema language is also simple idiomatic structures nearly everywhere, but a restricted profile of JSON Schema would get you there much faster than starting from the ground up.

drdaeman 2y ago
> narrow down to something where what can be defined in the schema language is also simple idiomatic structures nearly everywhere It feels more like a lowest common denominator to me, which is frequently (in presence of anything non-trivial) the opposite of idiomatic. For example, JSON does not have monetary/decimal type, best option available is a string. It would be very opposite of idiomatic to have a C# or Python code use a string in the record/dataclass, instead of a decimal, if the actual JSON document field has the "monetary value" semantic. And TypeSchema seem to ignore aspects like nullability and presence requirements, making assumptions that everything can be null (which can be wrong and even harmful, as if Java haven't taught us anything). Maybe I'm thinking wrong about it and the idea is to have separate wire and public API formats, though, where the wire format is minimal JSON (TypeSchema can work, I guess, although I still have concerns about nulls - and distinguishing between nulls and absence of the field) and then that intermediate almost-over-the-wire-but-deserialized-from-JSON-blob object representation is adapted into a language-specific idiomatic structure. I always felt that such approach is way too verbose and adds a lot of boilerplate without a good reason, but I could be wrong about it.
- dragonwriter 2y ago
  Yeah, “idiomatic” may have been a poor word choice, I really meant closer to “simply representable”. oneOf, for instance, lets you very easily define flexible, concise structures in JSON Schema that OO languages without union types may not express naturally if at all, and which may not be natural to work with even if they cna be expressed in many languages.
  - drdaeman 2y ago
    This makes sense, but I think it's even a better reason to not use a code generator (which forces certain patterns on your code), but rather think about the best language-native way to express a certain concept you want to express.
andix 2y ago
Restricting JSON Schema would've been my approach to this "problem" too.
HelloNurse 2y ago
Priority to high quality generation of good code from nice schemas that allow it (accepting that the schemas will be not very expressive and often too loose) vs. priority to faithfully representing and validating JSON documents that conform to general, detailed schemas (accepting that code generation won't be particularly flexible).

drdaeman 2y ago

> narrow down to something where what can be defined in the schema language is also simple idiomatic structures nearly everywhere It feels more like a lowest common denominator to me, which is frequently (in presence of anything non-trivial) the opposite of idiomatic. For example, JSON does not have monetary/decimal type, best option available is a string. It would be very opposite of idiomatic to have a C# or Python code use a string in the record/dataclass, instead of a decimal, if the actual JSON document field has the "monetary value" semantic. And TypeSchema seem to ignore aspects like nullability and presence requirements, making assumptions that everything can be null (which can be wrong and even harmful, as if Java haven't taught us anything). Maybe I'm thinking wrong about it and the idea is to have separate wire and public API formats, though, where the wire format is minimal JSON (TypeSchema can work, I guess, although I still have concerns about nulls - and distinguishing between nulls and absence of the field) and then that intermediate almost-over-the-wire-but-deserialized-from-JSON-blob object representation is adapted into a language-specific idiomatic structure. I always felt that such approach is way too verbose and adds a lot of boilerplate without a good reason, but I could be wrong about it.

dragonwriter 2y ago
Yeah, “idiomatic” may have been a poor word choice, I really meant closer to “simply representable”. oneOf, for instance, lets you very easily define flexible, concise structures in JSON Schema that OO languages without union types may not express naturally if at all, and which may not be natural to work with even if they cna be expressed in many languages.
- drdaeman 2y ago
  This makes sense, but I think it's even a better reason to not use a code generator (which forces certain patterns on your code), but rather think about the best language-native way to express a certain concept you want to express.

andix 2y ago

Restricting JSON Schema would've been my approach to this "problem" too.

HelloNurse 2y ago

Priority to high quality generation of good code from nice schemas that allow it (accepting that the schemas will be not very expressive and often too loose) vs. priority to faithfully representing and validating JSON documents that conform to general, detailed schemas (accepting that code generation won't be particularly flexible).