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

61–70 of 188 posts

Re: JSON Schema bundling formalised

#61

Post by paulddraper »

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.

I use JSONSchema a lot. It's as pleasant as one would reasonable expect.

Re: JSON Schema bundling formalised

#62

Post by Someone »

matja wrote: post #51
ChrisMarshallNY wrote: post #44

Earlier quoted context omitted.

This is where I would also develop an XML variant, even if it is never to be used, simply so that I can have a Schema to go along with it. I'll start with a data structure/class, in the code, then use a built-in transformer, to turn it into JSON or XML. That way, I know that the "kernel" of the data is the same, between them. Even though JSON is a "natural" for scalar types, it can get weird, there. For example, let'…

Even with integers (comes up often for large numeric IDs): JSON.stringify(JSON.parse('{"kids":10000000000000001}')) -> '{"kids":10000000000000000}' How do JSON schemas handle "must be an integer", and having to pass a string to get the necessary value?

That’s not an issue with json, but with json libraries. For better or (IMO) for worse

  {“kids”: 12345678901234567890123456789012345678901234567890}
is perfectly legal json.

Re: JSON Schema bundling formalised

#63

Post by tylercrompton »

csmpltn wrote: post #2

We've come full circle back to XML SOAP. We should consider restricting the registration of .org domains to actual non-profit organizations, and restricting the use of words like "schema" and "standard" to things that have been fully certified as such by internationally accredited engineering bodies. This doesn't add anything on-top of the tools we've had 40 years ago. We're stuck with this everywhere now, all thanks…

> We should consider restricting the registration of .org domains to actual non-profit organizations

Too late for that

> We should consider […] restricting the use of words like "schema" and "standard" to things that have been fully certified as such by internationally accredited engineering bodies.

Too late for that and unenforceable

Re: JSON Schema bundling formalised

#64

Post by paulddraper »

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…

On the contrary, the error message immediately states exactly how the data is malformed.

Instead of just failing somewhere deep inside the app (even perhaps deferred to later) with "cannot read property of undefined... stack trace"

Re: JSON Schema bundling formalised

#65

Post by miohtama »

paulddraper wrote: post #54
csmpltn wrote: post #2

We've come full circle back to XML SOAP. We should consider restricting the registration of .org domains to actual non-profit organizations, and restricting the use of words like "schema" and "standard" to things that have been fully certified as such by internationally accredited engineering bodies. This doesn't add anything on-top of the tools we've had 40 years ago. We're stuck with this everywhere now, all thanks…

Do you mean XSD? XSD = JSONSchema WSDL = OpenAPI SOAP = there really isn't a direct analog maybe ""REST"" --- In any case, try creating a SOAP service and WSDL. It's literally so complex that most tutorials have to rely on an IDE to do it. Humans are simply not equal to the task. Yes, the purpose is similar, but only those who have never used them would think they're the same.

I did XSD validator back in 2003 and indeed this blog post gives me familiar vibes.

I do believe there has to be some sort of common schema format, but I have no idea how this problem could be solved cleanly in practice, even after 20 years.

Re: JSON Schema bundling formalised

#66

Post by m_st »

k__ wrote: post #58
paulddraper wrote: post #54

Earlier quoted context omitted.

Do you mean XSD? XSD = JSONSchema WSDL = OpenAPI SOAP = there really isn't a direct analog maybe ""REST"" --- In any case, try creating a SOAP service and WSDL. It's literally so complex that most tutorials have to rely on an IDE to do it. Humans are simply not equal to the task. Yes, the purpose is similar, but only those who have never used them would think they're the same.

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.

Re: JSON Schema bundling formalised

#67

Post by chiph »

jonny383 wrote: post #15

If someone tried to push this on my engineering team, they would be laughed out of my office and ridiculed for the idiocy of even suggesting such garbage. The best factor of JSON is being a schema-less, human readable format. Imagine having someone present this monstrosity to you with a straight face, thinking it's a good use for JSON.

That depends on if you're getting JSON data from someone you don't quite trust. For internal uses, sure. If a process sends you bad JSON you go talk to the team responsible.

But if someone outside your organization is sending you data (product orders, say) you want something like this to ensure it's well-formed before you start evaluating business logic & validation against it.

Re: JSON Schema bundling formalised

#68

Post by dgb23 »

csmpltn wrote: post #2

We've come full circle back to XML SOAP. We should consider restricting the registration of .org domains to actual non-profit organizations, and restricting the use of words like "schema" and "standard" to things that have been fully certified as such by internationally accredited engineering bodies. This doesn't add anything on-top of the tools we've had 40 years ago. We're stuck with this everywhere now, all thanks…

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 and clear language that is meant to be read and written by humans. Compare that to DTD, XML schema.

I think in terms of raw functionality, there are very strong parallels. And even though I'm not an XML hater, I find JSON simply more pleasant to work with.

The only fundamental advantage that I would give XML over JSON is the fact that you can encode meta data in XML in a more idiomatic, standard way via attributes. But we all know that is not how XML is being used. If the ecosystem around XML wasn't abusing attributes to encode core/primary data, then there would be a stronger argument for the language IMO.

Re: JSON Schema bundling formalised

#69

Post by atombender »

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 XML. The specifications for XML Schema, WSDL, XSLT, etc. were gigantic. XML Schema and WSDL are both so big they are split into multiple parts. XSLT 3.0 is maybe 500 pages when printed. Many of these originated in the wrong sort of place, designed by committee and from inside big enterprises like IBM, rather than being adopted from evolving practices.

With XML out of the way, we still need a way to represent structured data, and it turns out JSON is pretty good for that. JSON has problems, but its simplicity is what lead to it becoming so prevalent in the first place. Now, we also need a way to define the structure and format of that data, and JSON Schema is pretty good for that. I think JSON Schema could have been a bit simpler, but it's still nowhere near to making the same mistakes as XML Schema.

Re: JSON Schema bundling formalised

#70

Post by ivolimmen »

paulddraper wrote: post #54
csmpltn wrote: post #2

We've come full circle back to XML SOAP. We should consider restricting the registration of .org domains to actual non-profit organizations, and restricting the use of words like "schema" and "standard" to things that have been fully certified as such by internationally accredited engineering bodies. This doesn't add anything on-top of the tools we've had 40 years ago. We're stuck with this everywhere now, all thanks…

Do you mean XSD? XSD = JSONSchema WSDL = OpenAPI SOAP = there really isn't a direct analog maybe ""REST"" --- In any case, try creating a SOAP service and WSDL. It's literally so complex that most tutorials have to rely on an IDE to do it. Humans are simply not equal to the task. Yes, the purpose is similar, but only those who have never used them would think they're the same.

Well let's turn the statement around then: can you create a OpenAPI YAML by hand then? At least with XML and XSD you have proper auto complete.

I really no need see the need to use a schema for JSON. The only thing it has going for it compared to SOAP/XML is the fact the it faster parsing and that it has no schema.

Post reply on HN