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

61–66 of 66 posts

Re: The Last Breaking Change

#61

Post by mihaic »

_ZeD_ wrote: post #28
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).

> Can anyone mention some interesting projects/use-case for JSON Schema? finally come back to WSDL and SOAP. sorry, you may have "terrible flashbacks", but I enjoyed those days, where I could have clients and server code auto generated, with automatic validation and so on, and I felt all these "unstructured" data sent over json as "dark ages". I'm tired of writing again yet another rest client payload mapping by hand…

I actually did miss the feeling of being safe in the serialization/deserialization of my data when JSON became widespread, you're right.

These flashback were specifically about WSDL maintenance by hand (it was not very human readable), and how the existence of a schema was used as an excuse to not actually document the meaning of certain fields.

I guess it depends a lot on people, but it seems like most systems need to be robust to idiots to some degree the more widespread they become.

Re: The Last Breaking Change

#62

Post by mst »

IshKebab wrote: post #44
mst wrote: post #41

Earlier quoted context omitted.

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.

I do see what you're getting at but in the SQL case an unhinted statement can potentially produce such a terrible plan it invariably times out and triggers a 500 from the service making the query.

This sort of thing somewhat blurs the boundaries between affecting performance and affecting behaviour.

I'm not claiming that there's an obviously right answer here, only that there can be more questions about whether something is a good idea on net than people always consider.

Note: It would not surprise me to find that the actual motivation for leaving comments out of JSON went something like:

1) We can't have line comments because we don't want to be newline sensitive that way 2) If we do /* ... */ style comments people -will- write incompatible parsers for them no matter how carefully we specify them 3) Argh

but I wasn't there at the time, so the question will have to remain open.

Re: The Last Breaking Change

#63

Post by grey-area »

noctune wrote: post #29
grey-area wrote: post #24

Earlier quoted context omitted.

What’s wrong with using a ‘comment’ key? I’d say not supporting large ints is worse. https://stackoverflow.com/questions/209869/what-is-the-accep...

JSON supports numbers of arbitrary and just fine. It's just many reader/writers of JSON does not, and those are so ubiquitous that it's often not practical to use.

Unfortunately in practice you can’t rely on large numbers being passed through correctly because of this, unless you control both ends and don’t use js.

Re: The Last Breaking Change

#64

Post by grey-area »

Uvix wrote: post #52
grey-area wrote: post #24

Earlier quoted context omitted.

What’s wrong with using a ‘comment’ key? I’d say not supporting large ints is worse. https://stackoverflow.com/questions/209869/what-is-the-accep...

A comment key works for commenting JSON objects, but not for commenting specific keys on an object or values in an array.

I don’t find that a huge limitation personally. I don’t think data formats should allow comments on values, that is what docs are for.

Re: The Last Breaking Change

#65

Post by solarkraft »

grey-area wrote: post #24
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.

What’s wrong with using a ‘comment’ key? I’d say not supporting large ints is worse. https://stackoverflow.com/questions/209869/what-is-the-accep...

It's pretty inconvenient and ends up in the data, rather than being external to it.

Re: The Last Breaking Change

#66

Post by relequestual »

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

Here's a YouTube playlist of 6 case studies with companies of various sizes: https://www.youtube.com/watch?v=fkziMQD7pqQ&list=PLHVhS4Tj1Y...

There are also two written case studies on the JSON Schema blog: https://json-schema.org/blog/

Post reply on HN