Live data from Hacker News

Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

news.ycombinator.com

171–179 of 179 posts

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#171
post #156

Earlier quoted context omitted.

Actually, currently, this is not the case. The specification explicitly allows for additional fields for the purposes of extensions. We are considering changing that, and only allowing pre-defined fields, or having a way to mark specific fields as limited extensions.

Huh, you're right. There is additionalProperties, but I mistakenly thought `"additionalProperties": false` was the default.

It is not =]

Additionally, the value is a "schema" as opposed to a boolean, meaning you can apply a subschema to any additional fields. Useful if you for instance want to make sure any additional fields start with a specific prefix.

Booleans are valid schemas. It's subschemas all the way down! I wrote an article around this topic: https://json-schema.org/blog/posts/applicability-json-schema...

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#172
post #97

Earlier quoted context omitted.

Ditto. It took me a while (coming from C++) to get that types are not the ideal source of truth in TypeScript, due to their disappearance at runtime. Having a runtime parser (which can consequently express things impossible with TypeScript types alone, like "a positive integer" rather than being satisfied with any instance of `number`) from which types are inferred, is a needed mindset shift made easy with Zod. I use…

Maybe I was unclear - my post was a criticism of Zod because it involves a bunch of duct tape that I'm not sure makes sense. Typebox just creates JSON Schema objects at runtime and projects them into the type system with `Static `. In so doing, you simultaneously create schema and types and the process of doing so is pleasant--you can just hand a TObject to Fastify as a validator object and you're done. Plus, with a…

Zod has the same "simultaneously create schema and types and the process of doing so is pleasant" feature, it's just not using JSON Schema for it (and has more power than JSON schema does).

In the Zod world, if you need JSON Schema to e.g. communicate to the outside world, you can extract it from the Zod schema with https://github.com/StefanTerdell/zod-to-json-schema -- but if you don't, you don't.

JSON Schema is kind of underpowered for real validation, so if you limit yourself to it, then you'll just have a another round of validation immediately after. TypeBox' s CreateType seems to be the same idea, it cannot be expressed in just JSON Schema.

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#173

Earlier quoted context omitted.

Zod schemas are the source of truth, from which TS types are inferred and JSON schemas are generated.

Interesting.. I'd rather write typescript types than Zod schemas. I haven't used JSON schema, but going TS to Zod was straightforward and really pleasant

That way does not give you runtime validation of input.

(Or, requires an extra build step to generate that. It's beyond Typescript itself.)

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#174
post #106

Earlier quoted context omitted.

what was the problem? there's templates and queries and it seemed pretty clear once you read a quick intro.

Namespaces in XML was a bit of a bolt-on, and really showed the difference between the crowd who wanted to create XML to simplify defining new markup languages like HTML (the originators) and the XML as data crowd who wanted generalized tooling to support all XML data. XPath really started to show the warts here - it leveraged namespaces as an axis, where your XPath could utilize namespaces which were defined at a pa…

They really should have made namespaces just be {url} prefixes on element and attribute names.

http://my.example.com/ns/fruit}citrus> ... http://my.example.com/ns/fruit}citrus>

Sure, it's textual bloat, but XML was already verbose and already compressed well with gzip, and it's a lot simpler to process.

The problem with the xmlns:alias="url" rewriting thing was that 1) most things didn't bother implementing it in full, and ended up e.g. relying on the name of the chosen alias 2) it had a special case of changing the current default namespace, which caused even more bad implementations.

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#175

I use JSONschema, it's honestly great the way it is [0]. So I guess the guarantee I want is "don't change anything"? Ha. [0] my biggest gripe is it's not well defined what to do with multipleOf when the number isn't an exact integer.

The behavior is perfectly well defined... there's no special cases for integers vs. rational numbers, they're all the same. For example, given multipleOf: 0.3, and an input of 0.9, 0.9/0.3 is 3, which is an integer, so would be accepted. A value of 0.8 would be rejected.

[deleted]

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#176
My struggle with JSON Schema is that not everyone uses it! I do a lot of work with various APIs and ingestion systems that accept JSON, but they don't provide a JSON Schema for me to validate my payloads against. Instead, I often have a human being on the other side emailing me and saying, "Your data structure isn't correct."

It's mildly infuriating. I've taken to using Cuelang[0] to write my own validators based on their specifications. (Using Cue because JSON isn't the only data format I have to support.)

I wish there were an easier way to take some documentation and generate JSON Schema from it. I can take the sample JSON in the docs and generate one, but those samples don't usually contain all the edge cases that the systems complain about, so it's not super useful.

[0] https://cuelang.org/

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#177
post #97

Earlier quoted context omitted.

Maybe I was unclear - my post was a criticism of Zod because it involves a bunch of duct tape that I'm not sure makes sense. Typebox just creates JSON Schema objects at runtime and projects them into the type system with `Static `. In so doing, you simultaneously create schema and types and the process of doing so is pleasant--you can just hand a TObject to Fastify as a validator object and you're done. Plus, with a…

Zod has the same "simultaneously create schema and types and the process of doing so is pleasant" feature, it's just not using JSON Schema for it (and has more power than JSON schema does). In the Zod world, if you need JSON Schema to e.g. communicate to the outside world, you can extract it from the Zod schema with https://github.com/StefanTerdell/zod-to-json-schema -- but if you don't, you don't. JSON Schema is kin…

I think Colin's a rad programmer, he works on EdgeDB which is absolutely my favorite datastore I've ever used and I think Zod's fine if you want to use it. But I don't agree with your premise. I don't, in practice, find the way Zod asks you to think about data compelling. It's probably because I think specifically in communication between systems; making the particulars of the interchange format central to the act of writing the thing, for me, keeps top-of-mind the necessity of both ends having an identical understanding of the allowable semantics. (Similarly, I've never used any Typebox features that don't map to JSON Schema, and I've never felt the need to.)

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#178
post #6

It really needs comments. Unfortunately it'll never be backwards compatible. It's very helpful for debugging

It already has comments[1]? [1]: https://json-schema.org/understanding-json-schema/reference/...

I guess I mean like commenting out a whole line like in JavaScript

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#179
post #53

Earlier quoted context omitted.

Isn't that a great example of something that would benefit from comments; a generically named int array with no context? Regarding the ability to add comments to JSON, it can be done in a cumbersome manner, such as adding a field to an object called "comment", but it is a hack since this wont work for arrays anyway.

The point is that JSON is a data structure, comment is rather unnatural there. It can be added to JSON though, just like an array could be wrapped in an object with a "comment" field. Usually array name serves as a crude comment. Literate programming isn't very popular.

> The point is that JSON is a data structure

JSON is not a data structure. JSON is a data language. A computer program is a data structure and doesn't need comments, a programming language is a format for a human to read, write, and interact with automated tooling, whoss content is a program, but for the human uses, comments are important.

Similarly for data languages.

Post reply on HN