Live data from Hacker News

Show HN: TypeSchema – A JSON specification to describe data models

typeschema.org

41–50 of 52 posts

Re: Show HN: TypeSchema – A JSON specification to describe data models

#41
post #10

Earlier quoted context omitted.

"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.

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…

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).

Re: Show HN: TypeSchema – A JSON specification to describe data models

#42
post #37

Why reinvent https://json-schema.org ?? Pros/cons?

json schema has nuanced and expressive constraints to validate information exchanged in json serialization. typeschema in contrast seems to focus on describing just the structure of data with the goal to generate stubs in a wide variety of programming languages.

so why not sub-setting JSON Schema? Like done with XML Infoset for example compared to XSD. And extensions are also possible to achieve POCO details as needed.

Re: Show HN: TypeSchema – A JSON specification to describe data models

#43

Kotlin classes are (seemingly) all generated as open classes, rather than data classes. Surprising choice - is this an intentional design decision? Wondering if I am missing something

The output in various languages in rather questionable. Not wrong per-se as it's totally valid code, but just.. not idiomatic and not how a developer fluent in that language would implement it.

Re: Show HN: TypeSchema – A JSON specification to describe data models

#44

Three big downturns for me: 1) They do not publish rationale of why the world needs yet another protocol / language / framework on the homepage. It is hidden in https://typeschema.org/history 2) In the history page, they confuse strongly typed and statically typed languages. I have a prejudice about people doing this. 3) The biggest challenge about data models is not auto-generated code (that many people would avoid…

Point #1 was my biggest turn off. Numbers 2 and 3 are good points too.

Re: Show HN: TypeSchema – A JSON specification to describe data models

#45

Three big downturns for me: 1) They do not publish rationale of why the world needs yet another protocol / language / framework on the homepage. It is hidden in https://typeschema.org/history 2) In the history page, they confuse strongly typed and statically typed languages. I have a prejudice about people doing this. 3) The biggest challenge about data models is not auto-generated code (that many people would avoid…

> ... auto-generated code (that many people would avoid in principle anyway)

Auto generated code is 100% enough, sometimes.

Re: Show HN: TypeSchema – A JSON specification to describe data models

#47

Three big downturns for me: 1) They do not publish rationale of why the world needs yet another protocol / language / framework on the homepage. It is hidden in https://typeschema.org/history 2) In the history page, they confuse strongly typed and statically typed languages. I have a prejudice about people doing this. 3) The biggest challenge about data models is not auto-generated code (that many people would avoid…

> 1) Yet another protocol etc.

Agreed.

> 3) The biggest challenge about data models is not auto-generated code

I would say auto-generated code is most definitely the harder problem to solve, and I’d also go out on a limb and say it is THE problem to solve.

Whether it’s JSON, XML, JavaScript, SQL, or what have you, integrating both data and behavior between languages is paramount. But nothing has changed in the last 40+ years solving this problem, we still generate code the same clumsy way… Chinese wall between systems, separate build steps, and all the problems that go with it.

Something like project manifold[1] for the jvm world is in my view the way forward. Shrug.

1. https://github.com/manifold-systems/manifold

Re: Show HN: TypeSchema – A JSON specification to describe data models

#48

Three big downturns for me: 1) They do not publish rationale of why the world needs yet another protocol / language / framework on the homepage. It is hidden in https://typeschema.org/history 2) In the history page, they confuse strongly typed and statically typed languages. I have a prejudice about people doing this. 3) The biggest challenge about data models is not auto-generated code (that many people would avoid…

I mean, Java and Go are strongly typed languages if you consider Object a = new Integer(); a = new Float(); to be strong.

They are also strict of cause

Re: Show HN: TypeSchema – A JSON specification to describe data models

#49
I once read a paper about Apache/Meta Thrift [1,2]. Similarly, it allows the definition of data types/interfaces and code generation for many programming languages. It was specifically designed for RPCs and microservices.

[1]: https://thrift.apache.org/

[2]: https://github.com/facebook/fbthrift

Re: Show HN: TypeSchema – A JSON specification to describe data models

#50
post #45

Three big downturns for me: 1) They do not publish rationale of why the world needs yet another protocol / language / framework on the homepage. It is hidden in https://typeschema.org/history 2) In the history page, they confuse strongly typed and statically typed languages. I have a prejudice about people doing this. 3) The biggest challenge about data models is not auto-generated code (that many people would avoid…

> ... auto-generated code (that many people would avoid in principle anyway) Auto generated code is 100% enough, sometimes.

I still have not found any way to use autogenerated code for Java/Spring that can handle updates to an external OpenAPI spec.

Any pointers?

(Serious question).

Post reply on HN