From the history page:
> JSON Schema is a constraint system which is designed to validate JSON data. Such a constraint system is not great for code generation, with TypeSchema our focus is to model data to be able to generate high quality code.
Well, types themselves are another type of constraint; specifying something like the type (number) of a property (Age) is a constraint on the possible values for that property.
> For code generators it is difficult to work with JSON Schema since it is designed to validate JSON data
There's lots of features in JSON Schema, but if you're writing a code generator, you don't actually to have support all of them. Some languages like C# don't have native lang support for AllOf, but do support OneOf or AnyOf.
> JSON Schema has many keywords which contain logic like dependencies, not, if/then/else which are basically not needed for code generators and really complicates building them.
So isn't the whole point of code generators for OpenAPI/JSON Schema is that they generate code to map foreign data sources in a target programming language so that the programmer doesn't have to write all this mapping code by hand? The vast majority of all programming languages support if/then/else and even modelling dependencies like what JSON Schema supports. So why is it a bad thing if a schema language like JSON Schema supports these constraints? Wouldn't having support for this in the schema language and a code generator mean less handwritten code and more time saved?
If a schema constrained Person.Age to be an integer always greater than 0, I would actually really love for that validation code to be generated for me. Chances are, if such constraints exist in the schema, then the vendor/original author probably has good reason to include them; having it code generated automatically means I don't have to worry about writing it myself.
I mean if you want to generate the code for only defining data structures & their properties, you can still do that, and just stop there. A whole new schema language in JSON seems wholly redundant. It seems like maybe the authors should've started with writing their own better code generator for JSON Schema rather than their whole new schema language and code generator.
Finally, reading the spec https://typeschema.org/specification, I can't see support for optional values or null/nullable types. I'm hoping it's just an oversight (seeing as how the spec itself is incredibly brief), but if it isn't, then bluntly, then this isn't ready for release.