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

JSON Schema bundling formalised

json-schema.org

Post reply on HN
Print view View original

151–160 of 188 posts

Re: JSON Schema bundling formalised

#151

Post by kords »

shados wrote: post #96
atombender wrote: post #69

I'll be one of the few positive voices here, I guess. JSON Schema is pretty good. It's a relatively simple, extensible, pragmatic specification that supports validating the kinds of data that JSON can express. XML was killed by complexity, same as lots of technologies that preceded it, such as CORBA and SOAP. Developers don't like complexity. W3C tried to build an enormously complicated ecosystem of tools on top of X…

This. Back in the XML days, I had to spend way to long reading XSLT and WSDL specs just to do basic things. JSON Schema takes 15 minutes to learn and it's a heck of a lot better than writing my own validator.

I remember I was enjoying XSLT; I used it to create templates and, in the end, valid XHTML pages. I thought that's the future.

Re: JSON Schema bundling formalised

#152

Post by spookthesunset »

xienze wrote: post #146
theamk wrote: post #141

Earlier quoted context omitted.

You missed the word "nice" in the GP's message. Also "(Not technically, but in practice, due to its complexity.)" No one says it is proprietary technology and yes, it is nominally standardized. It is just so complex that it is impossible to use without heavy tooling support, and this tooling is only really usable in Microsoft's technology. So it seems that people who use MS ecosystem like SOAP ... while almost everyo…

> It is just so complex that it is impossible to use without heavy tooling support, and this tooling is only really usable in Microsoft's technology. Again, gotta call BS here. My early career was 100% SOAP and related WS-* technologies. And it was all in Java, Apache Axis and friends. Wildly popular at the time. Give it your WSDL, out pops a nice Java client. People didn’t like it not because it was difficult to use…

Try calling a soap service with python. Oh boy enjoy the pain!

Re: JSON Schema bundling formalised

#153

Post by spookthesunset »

chrisjc wrote: post #91
solids wrote: post #50

Earlier quoted context omitted.

I agree with you, I didn’t expect the amount of negative comments. Used in the past and it was a great tool to “avoid representing invalid states” and also as documentation to share between teams.

> I didn’t expect the amount of negative comments I did! It's been made clear time and time again on HN that "everyone" HATES XML and anything to do with it... especially XSD, WSDL, etc! I really don't see any difference between XML and JSON except the semantics (I lie, I see a lot of reasons why XML is more powerful). But I do get why people prefer JSON over XML for visual reasons alone. Since they're very similar l…

> Something changes on the server-side, some edge case appears on the UI several weeks after release to prod.

Schemas don’t fix this problem. The reason the thing probably broke is the change wasn’t backwards compatible with the clients calling the service. No schema will fix that.

If the client hasn’t been updated to consume the breaking change it is gonna break, period. Schemas don’t get you out of handling breaking changes to your API.

That being said they might expose an unintentional breaking change in automated testing of the server. Which, I suppose, is a good thing. I mean using a standard tool for schema validation in testing… yeah I can get on board with that.

But no schema validation will ever be able to “fix” an intentional breaking change to an API.

In conclusion, writing this comment now has me kinda on board with schema validation for automated testing. It probably won’t catch all forms of unintentional breaking changes but it could catch some.

Re: JSON Schema bundling formalised

#154

Post by spookthesunset »

akie wrote: post #3

I might be exceptionally dense, but it's hard for me to see practical applications for something like this. In the end, if you implement this in your application, you will have a mechanism to say "this input document is invalid". AND THEN WHAT? Your only option is to discard it. I'd rather live by the old maxim "be liberal in what you accept, and strict in what you produce". But perhaps I'm overlooking an important u…

I made an argument like yours and kinda talked myself out of it.

Validation while in production makes no sense, I agree. But automated testing… I bet you can catch some unintentional changes to your JSON output while testing. Not all of them, but some. Maybe even enough to justify keeping the schema current.

Re: JSON Schema bundling formalised

#155

Post by spookthesunset »

Vinnl wrote: post #16
akie wrote: post #3

I might be exceptionally dense, but it's hard for me to see practical applications for something like this. In the end, if you implement this in your application, you will have a mechanism to say "this input document is invalid". AND THEN WHAT? Your only option is to discard it. I'd rather live by the old maxim "be liberal in what you accept, and strict in what you produce". But perhaps I'm overlooking an important u…

I'm relatively often manually editing `package.json` files in npm projects - it's useful if my editor can highlight when I make a typo.

Ah yeah, that was one of the nice things about XML documents that had a well managed XSD backing it up. Visual Studio code completion worked on your XML files!

XAML, for example, would suck if it didn't have a bunch of XSD mumbo jumbo backing it up.

Re: JSON Schema bundling formalised

#156

Post by spookthesunset »

streamofdigits wrote: post #136

Never had to learn the intimidating XML stack in depth but it seems clear that the (superficially definetely more digestible) JSON way of notating data must slowly and painfully reinvent the wheel. Reaching the same level of logical complexity (if it solves the same set of problems) seems unavoidable, no? So if the main advantage of JSON is human readability (not a machine oriented attribute btw :-) might be possible…

What makes JSON so nice to use is it is basically how you already write complex data structures in most loosely typed languages anyway. JSON documents look a hell of a lot like how you'd write the same structure in PERL, python, javascript, and more.

It provides a very natural mapping into the types of native data structures these languages offer. Dumping native data structures in these languages out to JSON is trivial. Dumping these same data structures into XML was always a pain in the ass because you'd have to manually map every field into elements and attributes.

Re: JSON Schema bundling formalised

#157

Post by dnautics »

mstade wrote: post #127
atombender wrote: post #69

I'll be one of the few positive voices here, I guess. JSON Schema is pretty good. It's a relatively simple, extensible, pragmatic specification that supports validating the kinds of data that JSON can express. XML was killed by complexity, same as lots of technologies that preceded it, such as CORBA and SOAP. Developers don't like complexity. W3C tried to build an enormously complicated ecosystem of tools on top of X…

> I think JSON Schema could have been a bit simpler, but it's still nowhere near to making the same mistakes as XML Schema. Agree with every single one of your points, and this in particular. Thankfully, there are some heroes out there developing excellent tooling to make working with JSON schema easier. I've been making good use of Ajv[1], and highly recommend it to anyone having to deal with JSON payloads and schem…

I used to resent the changes between the draft JSONSchema, but on reflection, almost all of them have been, IMO, extremely well chosen.

Re: JSON Schema bundling formalised

#158

Post by dnautics »

SV_BubbleTime wrote: post #142
espadrine wrote: post #133

Earlier quoted context omitted.

One thing I am wondering is whether the protobuf folks have a better development environment overall, or a worse one. Is the schema-to-self-validating-serialization-code approach going to win just as JSON won over XML?

This is what I was thinking, but no, skeptical. Protobufs are far more efficient, but dump the human readability for the data transfer, and that is where the logging and debugging happen quite a bit. As to code generation, if you use someone’s package for confirm_my_schema(thisjson) isn’t that basically code generation just moved somewhere else?

not all jsonschema validators are codegen/macros, so some of them are relatively unperformant and come with a lot of code baggage.

Re: JSON Schema bundling formalised

#160

Post by dehrmann »

kords wrote: post #151
shados wrote: post #96

Earlier quoted context omitted.

This. Back in the XML days, I had to spend way to long reading XSLT and WSDL specs just to do basic things. JSON Schema takes 15 minutes to learn and it's a heck of a lot better than writing my own validator.

I remember I was enjoying XSLT; I used it to create templates and, in the end, valid XHTML pages. I thought that's the future.

It is a functional language, and the cool kids are really into those.
Post reply on HN