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

91–100 of 188 posts

Re: JSON Schema bundling formalised

#91

Post by chrisjc »

solids wrote: post #50
jacobmischka wrote: post #18

I'd like to offer a contrasting opinion to all of the other currently negative comments: I've used JSON schema in the past to validate outside input and it was a pleasant and straightforward experience. There are unfortunately no standard type declarations that I'm aware of, which is a pain, but tools exist to translate schema.org schemas[1] (I have not used this myself). [1]: https://github.com/charlestati/schema-or…

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 logically/structurally, it only makes sense that the same things that are possible with XML are possible with JSON. And here we are, discussing JSON schemas!

So is it really that they hate XML and love JSON for any other reason besides the visual ones?

If not, what is it that they hate?

I think it has to do with the responsibility and effort that goes into creating a contract, the "schema". All the anxiety and headbanging that goes into setting up all the meetings and discussions. All the convincing that happens over and over again just to move forward. All of the back-and-forth that goes into whether it's this type or that bc the requirements are ambiguous to begin with and now it's the developer's responsibility. "I could just throw this API together in a day if it wasn't for all these useless meetings. Why do I have to wait for Bob to update the schema when I can just cast this field to a boolean in my code?". "I don't want to have to deal with validation exceptions at runtime, just fix your damn code and read the wiki I put together." etc.

(I do understand that not all APIs, data exchange files, tightly coupled project, etc... need schemas)

In my experience, while these schema-less approaches lead to projects being leaner and completed sooner, the price is payed continuously there after. Something changes on the server-side, some edge case appears on the UI several weeks after release to prod. Enhance the structure, breaks ETLs. And so on.

A perceptual state of keeping everything in tranquility emerges.

Re: JSON Schema bundling formalised

#93

Post by dolmen »

oaiey wrote: post #77
dgb23 wrote: post #68

Earlier quoted context omitted.

JSON syntax is more familiar for people who have not been exposed to XML for long. Parsing and walking a JSON structure is much easier and less ambiguous. It's often very clear how to represent/deserialize/serialize JSON (as-is). The benefits of using schema are clear, you can add validation and semantics to parse (JSON) into a richer and more consistent data structure. JSON-schema is in large parts a well designed a…

XSD is not as bad as everyone claims. JSON Schema vs. XSD complexity is IMHO pretty much the same. Working with both over years. DTD however, let us not talk about that. Let us just forget it. I think the drama in XML usage was basically that a simple RPC (or resource query) had at least a dozen namespaces, standards and very long element names. But that is not the fault of XML but of SOAP/WS-*. XML itself can be ver…

> I think the drama in XML usage ...

What about:

- verbosity

- complexity of writing a parser

- complexity of dumping data

- DTDs

- data model which doesn't map directly to a scalar/array/associative array

... and so many other XML features that are either useless or painful just for RPC.

Re: JSON Schema bundling formalised

#94

Post by shados »

indymike wrote: post #86
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…

> Developers don't like complexity. Judging by the code that is in front of me right now, I'm pretty sure they really do like it... or at least make lots of it.

They like to produce complexity, else they get bored while writing the code. But they don't like OTHER developer's complexity.

Re: JSON Schema bundling formalised

#95

Post by michaelmior »

chmod775 wrote: post #22
conceptme wrote: post #14

Earlier quoted context omitted.

afaik there is no integer type in json but a numeric type, and most languages do have different numeric types.

Neither is 'non negative' - but that should also be a built-in, considering how verbose the language becomes otherwise. Now you're adding ~5 lines of boilerplate every time you want to have an integer, another 5 for positive integers, and so on.

To support non-negative integers, all you need is the following

{"type": "integer", "minimum": 0}

I think the format used in the example was used to demonstrate bundling, but if what you really want is a non-negative integer, the above is the simplest way to do it.

Re: JSON Schema bundling formalised

#96

Post by shados »

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.

Re: JSON Schema bundling formalised

#97

Post by run-types »

For those looking to sanitize input from Typescript, I highly recommend the runtypes library: https://github.com/pelotom/runtypes

It let's you specify type definitions a DSL in Typescript using syntax very similar to Typescript's type definitions. Once you define your types in the DSL, you get Typescript types and parsing / verification for free. Not as general purpose as JSON Schema, but 1000x cleaner and easier to use.

Re: JSON Schema bundling formalised

#98

Post by lolive »

arethuza wrote: post #71
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…

Strongly agree - I've worked with ONC RPC, CORBA, SOAP, XML & XSD, XSLT etc. and I much prefer the relatively straightforward nature of JSON and JSON Schema. Yes it's not perfect - but for me it is more than good enough. Edit: Of course, there is no direct equivalent of XSLT in the JSON world - which pretty much counts as a feature to me.

Nor XPath.

Re: JSON Schema bundling formalised

#99

Post by dolmen »

m_st wrote: post #66
k__ wrote: post #58

Earlier quoted context omitted.

I had to use SOAP once... for one API endpoint. I'd say it was the worst dev experience of my whole career, and I fought with objective-c and app stores.

Using SOAP APIs daily since over 15 years with .NET Framework development. Simple and easy to write and then easy to consume through Visual Studio generated code. Tried some ObjC development early on the iPhone. Gave up quickly. I agree that SOAP looks like a mess. But given the right tools, it honestly just works. Never had a single issue with these APIs apart being stuck in .NET Framework land.

Looks like a case of Stockholm syndrom.

Re: JSON Schema bundling formalised

#100

Post by IggleSniggle »

akie wrote: post #87
vbezhenar wrote: post #48

Earlier quoted context omitted.

Why do you need to be liberal in what you accept, regarding to API? It just invites for subtle bugs. It makes sense for user-generated input, like phone numbers or addresses. But for software? You're encouraging buggy incomplete software that'll bite you or your client one way or another with that liberal approach. API must be absolutely strict and unambiguous. It helps everyone in the end. Or you'll end up with pars…

> This already helps to eliminate lots of unnecessary code. Well, I think you just moved the validation code to another place. Instead of putting it in your app, where (in my opinion) it belongs, you are putting it in a hard-to-read and difficult to understand external JSON file. I'm not sure how that's an improvement.

It’s an improvement because it’s a public contract that can be enforced both client(s) and server(s), and a relatively standardized interface format that is parseable by all manner of tooling.

Otherwise, it’s just in your code, where it’s potentially not just “hard-to-read”, but impossible to read for anybody but the authors.

That said, I’m partial to other solutions like protobuf, but what can you do.

Post reply on HN