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

41–50 of 66 posts

Re: The Last Breaking Change

#41

Post by mst »

IshKebab wrote: post #31
moring wrote: post #26

Earlier quoted context omitted.

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.

Things like comments being used to provide optimiser hints in SQL queries are the bane of people writing parsers or anything that depends on them.

I think folding/lint/etc. markers are poor examples here, because they're basically annotations for other tools which seems entirely fine.

However comments that affect the behaviour of the code itself are really much less fun to deal with.

Worrying that JSON implementations would end up acquiring the latter is pretty fair given our track record as a species.

Re: The Last Breaking Change

#42

Post by mst »

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.

I've always been fond of _x_ as a prefix for such things.

Re: The Last Breaking Change

#43

Post by mst »

rektide wrote: post #19
EdwardDiego wrote: post #18

Earlier quoted context omitted.

> brutal > ugly & rough conceitedness > Craven attitude > mean & awful Why do you phrase it in such emotive terms?

It's a terrible & self-interested & small-minded design philosophy making awful trade-offs. It's an actively dangerous way of building, to the exclusion of allowing possibility, and for false gain ("no new major versions but it will totally change maybe & no one else has freedom"). I use strong terms because this breaks so many internet ethos, logos, & pathos. Picking the narrowest path should be warded & hazarded ag…

They've explicitly said they're looking at finding a way to still be able to express custom properties.

So done right the end result will be basically no different from the use of X- headers in HTTP and friends.

What they're talking about doing could easily be -implemented- badly, but your reaction to the idea of doing it at all seems rather more exothermic than indicated by the situation.

Re: The Last Breaking Change

#44

Post by IshKebab »

mst wrote: post #41
IshKebab wrote: post #31

Earlier quoted context omitted.

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.

Things like comments being used to provide optimiser hints in SQL queries are the bane of people writing parsers or anything that depends on them. I think folding/lint/etc. markers are poor examples here, because they're basically annotations for other tools which seems entirely fine. However comments that affect the behaviour of the code itself are really much less fun to deal with. Worrying that JSON implementation…

> comments that affect the behaviour of the code itself...

I agree, but those are extremely rare in my experience. SQL optimiser hints and HDL synthesis hints only affect performance.

What examples are there of comments affecting actual behaviour such that tools must parse them for the code to even run?

I can't think of any.

Re: The Last Breaking Change

#45

Post by IshKebab »

joeblubaugh wrote: post #27

This takes JSON schema from a fairly lightweight, flexible definition to one of the most rigid. As much as I have a hairs time with dynamic languages, I can’t get with this. Feels contrary to the spirit of the JS ecosystem in the first place. Makes CUE a much more attractive way to directly validate JSON - you can declare with struct a are open or closed as part of the definition.

My issue with Cue is that there's no actual way to use it as a schema. At least I couldn't find a way to have one cue document link to another cue document so that e.g. IDEs can use the information.

Also the only language Cue supports is Go at the moment which makes it a bit of a non starter IMO.

It does have a quite elegant design, but I'm not sure it really solves enough to be worth the hassle, especially given that it doesn't attempt to solve the "make config less tedious using functions" problem.

Re: The Last Breaking Change

#46

Post by IshKebab »

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 makes editing JSON in IDEs way way nicer. Worth it for that alone IMO.

Re: The Last Breaking Change

#47

Post by jgalt212 »

alpaca128 wrote: post #38
singularity2001 wrote: post #23

Earlier quoted context omitted.

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.

what's the difference between JSON5 and the config language that vs code uses ,JSON + comments (as best I can tell).

Re: The Last Breaking Change

#48

Post by 9dev »

crabbone wrote: post #40
EdwardDiego wrote: post #16

Earlier quoted context omitted.

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, whic…

Just because you can doesn’t mean you should. If someone told me tags must appear in a specific sequence for their markup to work, I call the implementation flawed. That’s been the downfall of XML - doing way too much for it’s own good.

Re: The Last Breaking Change

#49

Post by moring »

mst wrote: post #41
IshKebab wrote: post #31

Earlier quoted context omitted.

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.

Things like comments being used to provide optimiser hints in SQL queries are the bane of people writing parsers or anything that depends on them. I think folding/lint/etc. markers are poor examples here, because they're basically annotations for other tools which seems entirely fine. However comments that affect the behaviour of the code itself are really much less fun to deal with. Worrying that JSON implementation…

> I think folding/lint/etc. markers are poor examples here, because they're > basically annotations for other tools which seems entirely fine. > > However comments that affect the behaviour of the code itself are really > much less fun to deal with.

I think there is no clear distinction between "hints for other tools" and "the behavior of the code itself" unless you implicitly assume a set of tools that define "the behavior of the code itself".

You could argue that HDL synthesis hints don't change the behavior of the code, nor do SQL optimizer hints.

I understand why you think that IDE folding hints are poor examples, but you would still force unrelated tools to leave those "comments" intact, possibly in cases where there is no clear definition of "intact" (massive transformations to the JSON structure). xkcd "spacebar heating" applies: https://xkcd.com/1172/

Re: The Last Breaking Change

#50

Post by crabbone »

9dev wrote: post #48
crabbone wrote: post #40

Earlier quoted context omitted.

> 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, whic…

Just because you can doesn’t mean you should. If someone told me tags must appear in a specific sequence for their markup to work, I call the implementation flawed. That’s been the downfall of XML - doing way too much for it’s own good.

> Just because you can doesn’t mean you should.

This is where you are wrong. If you are making a validator, if the format can do something, the validator should deal with that possibility. If validator is incomplete wrt' validated features, it cannot be used to guarantee the document validity, which is... well, it's most important function.

It has nothing to do with your emotional attachments to tags and sequences.

Post reply on HN