Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Last Breaking Change

json-schema.org

Post reply on HN
Print view View original

31–40 of 66 posts

Re: The Last Breaking Change

#31

Post by IshKebab »

moring wrote: post #26
smallstepforman wrote: post #11

For a format designed to be human readable, JSON not supporting comments is a major let down. And not supporting trailing comma.

Counterpoint: In practically every language that supports comments, these "comments" are now used for language extensions (IDE folding markers, eslint-ignore, FPGA synthesis hints, ...) Please don't do that to JSON.

What exactly is wrong with that? Comment hints like that are quite common and with a few exceptions (synthesis hints) they are all optional hints that have no effect on the main interpretation of the code. IDE folding markers aren't going to hurt anyone. Chrome doesn't care about lint waivers. Etc.

Re: The Last Breaking Change

#33

Post by jspdown »

EdwardDiego wrote: post #16
mihaic wrote: post #9

Can anyone mention some interesting projects/use-case for JSON Schema? I have terrible WSDL flashbacks from a past project, where the abstraction layer was always either too high (something simpler was better) or too low (and written documentation was better).

It's much the same as an XML schema, or K8s CRDs that have a schema embedded into the definition - schema are very useful for ensuring your data structure is valid. You can use the schema to validate that data is structured correctly, then apply business rule validations afterwards. And most importantly, people creating data you're ingesting have a thorough schema to validate against. The JSON Schema documentation wa…

Open API schema objects are define using JSON Schema. The latest version even let you specify the JSON Schema dialect.

Re: The Last Breaking Change

#34

Post by Karellen »

junon wrote: post #5

Underscore prefixes like C. Dedicated property to act as kitchen sinks, e.g. "custom", that says "anything in here is implementation specific". Simply not allowing custom keywords at all, also a good option. Have users write higher level schemas that compile down to jsonschema. All viable options.

The thing that confuses me is:

> A keyword is "known" if it is defined by a vocabulary listed in the schema's meta-schema (identified by the value in $schema).

    {
      "$schema": "https://json-schema.org/draft/2020-12/schema",
So, if a schema identifies as conforming to the 2020-12 meta-schema, why would a new "database-field-id" keyword in the 2025 upgrade be an issue? The 2025 parsers should know that it's not a keyword in the 2020-12 meta-schema, and treat it the same as they always did, shouldn't they?

But also - as an alternate to underscore prefixes, could new keywords just reuse the "$" prefix as in "$schema"?

Re: The Last Breaking Change

#35

Post by crabbone »

I could never bring myself to take JSON and family seriously. This is just another indication. I mean they didn't consider that it's not possible to have things that escape validation being made to validate in the future version? And these are the people which are making the validator software?

Re: The Last Breaking Change

#36

Post by beeforpork »

If the JSON file had a version number for the spec, then could could support future versions without breaking it, ever. Just define that all future versions will include the previous versions. E.g., specify that if a file is meant to be compliant with the next JSON version, then it needs to start with

#JSON1

And the next one with #JSON2. And if a JSON2 parser finds a JSON1 file, it should interpret it as JSON1. If a JSON1 parser finds a JSON2 file, it should try its best to parse it anyway, because your changes are not going to arbitrarily break stuff, right?

This is a breaking change, too, but it may indeed be the last one...

Re: The Last Breaking Change

#37

Post by crabbone »

beachy wrote: post #2

Admiring the chutzpah of declaring this will be the "last breaking change". We'll see! And perhaps json schema should borrow from http header conventions of old and allow unknown elements if prefixed in some way e.g: X-my-funky-element: true

It's probably "last" as in "latest".

Re: The Last Breaking Change

#38

Post by alpaca128 »

singularity2001 wrote: post #23
smallstepforman wrote: post #11

For a format designed to be human readable, JSON not supporting comments is a major let down. And not supporting trailing comma.

Adding comments to json is the one breaking change the world needs. As a parser if you stumble over a comment it's your fault! nothing in the world could stop you from just sanely ignoring comments.

JSON5 exists and allows both comments and trailing commas. It's basically like defining objects in plain JavaScript syntax.

Re: The Last Breaking Change

#39

Post by ChrisMarshallNY »

Well, time will tell.

If they get it right, people will use it.

If they don’t, it will wither on the vine.

Pretty darwinian, but This Is The Way.

XML Schema is a fiendishly complex, awkward, and verbose standard, but it is very much in use. Personally, I hate it, but I have used it fairly often.

I would like it to succeed, and will use it, if it does; even if it’s ugly. If it doesn’t work, I won’t use it.

My experience tells me that it can be next to impossible to predict what will and won’t work, and there’s probably no replacement for actually putting it out there and trying.

My experience also tells me that the most certain way to ensure failure, is to try predicting the future, and engineering for a very specific one.

Personally, I have had good luck, with an “heuristic” approach, where my designs act as a “lattice” for growth, and I evolve it, as I see the direction the project takes.

The main thing, in my experience, is to never have to go back and change stuff that has already been done. I may do new stuff, in the future, that breaks the API, but I should always honor The Old Ways.

Re: The Last Breaking Change

#40

Post by crabbone »

EdwardDiego wrote: post #16
mihaic wrote: post #9

Can anyone mention some interesting projects/use-case for JSON Schema? I have terrible WSDL flashbacks from a past project, where the abstraction layer was always either too high (something simpler was better) or too low (and written documentation was better).

It's much the same as an XML schema, or K8s CRDs that have a schema embedded into the definition - schema are very useful for ensuring your data structure is valid. You can use the schema to validate that data is structured correctly, then apply business rule validations afterwards. And most importantly, people creating data you're ingesting have a thorough schema to validate against. The JSON Schema documentation wa…

> It's much the same as an XML schema,

That's wishful thinking. I can find a lot of differences, but want to point out this one to underscore the difference in approach and level of sophistication.

So, in XSL (which is one of the XML schema languages), there's a sequence element. This element describes how tags are supposed to appear in certain order. The analogous structure in JSON would be the dictionary keys, which are also allowed to repeat... but the schema doesn't even cover that option! To make this more concrete, below, is a valid JSON:

    { "x": 1, "x": "2" }
But there's no way of describing in the schema what happens here. Not only this, XSL can restrict the number of times a certain element may repeat... but JSON schema cannot still figure out what to do about this.

There are plenty of things that can be implemented in various XML schema languages, but have nothing analogous to them in JSON schema. Another example would be ensuring uniqueness of some particular type of values across the entire document.

Post reply on HN