Show HN: TypeSchema – A JSON specification to describe data models
1–10 of 52 posts
Re: Show HN: TypeSchema – A JSON specification to describe data models
#2Comparison between TypeSchema and LinkML for those interested as I was. https://www.perplexity.ai/search/please-compare-and-contrast...
Re: Show HN: TypeSchema – A JSON specification to describe data models
#3What's the benefit over existing variants like Swagger/OpenAPI/JsonSchema ?
Re: Show HN: TypeSchema – A JSON specification to describe data models
#4What's the benefit over existing variants like Swagger/OpenAPI/JsonSchema ?
It feels like a convert solution, as it can transform TypeSchema into JsonSchema.
Re: Show HN: TypeSchema – A JSON specification to describe data models
#5What's the benefit over existing variants like Swagger/OpenAPI/JsonSchema ?
Heh feels like Json schema to me too... Same, but different.
Re: Show HN: TypeSchema – A JSON specification to describe data models
#6Obligatory https://xkcd.com/927/
Re: Show HN: TypeSchema – A JSON specification to describe data models
#7What's the benefit over existing variants like Swagger/OpenAPI/JsonSchema ?
Yeah, I'm not really following the line of reasoning presented on the "/history" page: https://typeschema.org/history
It seems to me like a mischaracterization of JSON Schema to say you can't define a concrete type without actual data.
I am a very stupid individual so I could be misunderstanding the argument.
Re: Show HN: TypeSchema – A JSON specification to describe data models
#8What's the benefit over existing variants like Swagger/OpenAPI/JsonSchema ?
Heh feels like Json schema to me too... Same, but different.
Feels much weaker/naive than JSON Schema, as TypeSchema barely has any constraints.
The TypeSchema spec is hard to comprehend as it doesn't delve into any details and looks like just a bunch of random examples with comments than a proper definitive document (e.g. they don't ever seem to define what "date-time" string format is). I don't see a way to say, e.g., that a string must be an UUIDv7, or that an integer must be non-negative, or support for heterogeneous collections, etc etc.
Maybe it has some uses for code generation across multiple languages for very simple JSON structures, but that feels like a very niche use case. And even then, if you have to hook up per-language validation logic anyway (and probably language-specific patterns too, to express concepts idiomatically), what's the point of a code generator?
Re: Show HN: TypeSchema – A JSON specification to describe data models
#9What's the benefit over existing variants like Swagger/OpenAPI/JsonSchema ?
It looks far more constrained, especially when it comes to the validation logic, which makes sense validation-wise but honestly quickly becomes a "fate shovels shit in my face" kind of situation when it comes to code generation. As much as I love this sort of constraints I also find the union-type discrimination style "meh".
Re: Show HN: TypeSchema – A JSON specification to describe data models
#10Earlier quoted context omitted.
Heh feels like Json schema to me too... Same, but different.
Feels much weaker/naive than JSON Schema, as TypeSchema barely has any constraints. The TypeSchema spec is hard to comprehend as it doesn't delve into any details and looks like just a bunch of random examples with comments than a proper definitive document (e.g. they don't ever seem to define what "date-time" string format is). I don't see a way to say, e.g., that a string must be an UUIDv7, or that an integer must…
"What is the difference to JSON Schema?
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."
They have more details on the History page.