[HN Gopher] Show HN: TypeSchema - A JSON specification to descri...
___________________________________________________________________
Show HN: TypeSchema - A JSON specification to describe data models
Author : k42b3
Score : 56 points
Date : 2024-10-24 19:46 UTC (3 hours ago)
(HTM) web link (typeschema.org)
(TXT) w3m dump (typeschema.org)
| Onawa wrote:
| Comparison between TypeSchema and LinkML for those interested as
| I was. https://www.perplexity.ai/search/please-compare-and-
| contrast...
| whizzter wrote:
| What's the benefit over existing variants like
| Swagger/OpenAPI/JsonSchema ?
| mariocesar wrote:
| It feels like a convert solution, as it can transform
| TypeSchema into JsonSchema.
| RedShift1 wrote:
| Heh feels like Json schema to me too... Same, but different.
| drdaeman wrote:
| 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?
| amanzi wrote:
| "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.
| drdaeman wrote:
| Yeah, I've edited my comment above and added the last
| paragraph with a note about it. Must be a really weird
| use case when you need to write a bunch of code in
| different languages (probably writing libraries for some
| API or JSON-based data interchange format?), and is also
| not concerned about validation and language - because if
| you need validation, you're writing code by hand either
| way, so code generation becomes a curse rather than a
| blessing.
|
| I would've understood if it would do the inverse - read
| source code in any of the supported languages, and check
| if the structures it define it conforms to the schema.
| That would make sense for testing that those structs
| aren't too diverging between codebases (have the same-
| shaped fields). Even then I'm not sure I see the point
| because various languages tend to use different language-
| specific things (like an UUID type or
| enums/symbols/atoms, etc.) to make developer feel at home
| rather than in a barren JSONland.
| dragonwriter wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| Restricting JSON Schema would've been my approach to this
| "problem" too.
| 8338550bff96 wrote:
| 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.
| andix wrote:
| I can't really follow those arguments either. For example the
| empty object example {}. Why is this bad? Types without
| properties are a real thing. Also an empty schema is a real
| thing.
|
| The thought I do get: JSON Schema primarily describes one
| main document (object/thing). And additionally defines named
| types (#/definitions/Student). But it's totally fine to just
| use the definitions for code generation.
|
| The reference semantics of JSON Schema is quite powerful, a
| little bit like XML with XSD and all the different imports
| and addons.
| mchicken wrote:
| 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".
| banga wrote:
| Obligatory https://xkcd.com/927/
| jdthedisciple wrote:
| ?
| cmgriffing wrote:
| I find it interesting that the Go serialization just duplicates
| the props rather than using composition:
| https://typeschema.org/example/go
|
| Seems a bit naively implemented.
|
| Ideally, the duplicated props in Student would just be a single
| line of `Human`.
| bobbylarrybobby wrote:
| The rust generator seems not to place generic parameters on the
| type itself?
|
| use serde::{Serialize, Deserialize}; #[derive(Serialize,
| Deserialize)] pub struct Map { #[serde(rename = "totalResults")]
| total_results: Option<u64>, #[serde(rename =
| "entries")] entries: Option<Vec<T>>, }
| simonw wrote:
| TypeScript but no JavaScript is a tiny bit disappointing. I still
| like to be able to work on front-end code without needing to run
| separate build tooling.
| creatonez wrote:
| This tool can convert to JSON Schema, so it can be used with
| validator libraries. Either way, validation and static duck
| typing based on schema are two separate concerns, and the
| latter is impossible without something like a Typescript
| compiler (or checker if using jsdoc-style Typescript).
| jdthedisciple wrote:
| If I had the spare time I would love to contribute dart support,
| but alas...
| georyb wrote:
| This is great. Some positivity, since many comments are on the
| negative side.
|
| It's exactly what I need to connect .py with .ts
| unmoeglich wrote:
| Ha?
| sevensor wrote:
| Why is everything nullable?
| benatkin wrote:
| Have you heard of wit? I suspect we'll see use outside of
| WebAssembly. https://component-
| model.bytecodealliance.org/design/wit.html
|
| It has non-nullable types, via option, which makes non-nullable
| the default, since you have to explicitly wrap it in option.
| https://component-model.bytecodealliance.org/design/wit.html...
|
| A way to represent types in other languages would be nice, but it
| would be better to start with something like wit and build on top
| of it, or at least have a lot of overlap with it.
___________________________________________________________________
(page generated 2024-10-24 23:00 UTC)