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

121–130 of 188 posts

Re: JSON Schema bundling formalised

#121

Post by no_wizard »

easrng wrote: post #83
oaiey wrote: post #77

Earlier quoted context omitted.

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…

It's easy in JS too, just use a DOMParser

That is not a JavaScript API, that’s a DOM only API, meaning it’s not reproduced in the language spec. This is important because it won’t work in Node, for example, without a 3rd party library or someone implementing it in Node core.

JSON however is supported in the language spec

Re: JSON Schema bundling formalised

#122

Post by onionisafruit »

shados wrote: post #94
indymike wrote: post #86

Earlier quoted context omitted.

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

There’s a crude expression about smells and feces that applies here.

I used to struggle to understand why other people didn’t like using all the clever abstractions I came up with. I felt unappreciated and thought I needed to learn how to communicate better. It turns out I was communicating just fine. What I needed to learn was how to accept feedback.

Re: JSON Schema bundling formalised

#123

Post by dgb23 »

staticassertion wrote: post #88
oaiey wrote: post #77

Earlier quoted context omitted.

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…

Maybe someone can chime in but parsing XML seems very much more difficult than parsing JSON.

Just the raw parsing is a solved problem from a user's perspective, the issue arises when you ask yourself "into what" you parse or rather what the semantics of the tree is.

It even might not matter whether you parse it programmatically or not in some cases. Typically when looking at a given XML (or other data structure text representations) you can pattern match the semantics of what you see, but that is not always true, because everyone uses it in a different way, relying almost completely on schema and documentation to convey semantics, which in turn makes the format strictly inferior to JSON, which also doesn't have rich semantics but is simpler.

Re: JSON Schema bundling formalised

#124

Post by speedbird »

gone35 wrote: post #5

History has not been kind to efforts like these.

Software "engineering" repeatedly goes through the same loop: - something simple, easy to learn, easy to use - doesn't cover edge case X - lacks rigour - lets add a bunch of features - and committees and processes to manage that - this is really complicated and hard to learn and use, we need something simpler ...

Re: JSON Schema bundling formalised

#125

Post by lolive »

jbverschoor wrote: post #110
shados wrote: post #94

Earlier quoted context omitted.

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

Yeah they (including younger me) loved abstractions and complexity I wrote or I read about. But it’s complex and difficult to grasp, so it’s not fun when you have to get into someone else’s mind, or even to get back into your own thinking after period of a sense of that project/architecture

The rule is "K.I.S.S (and add more RAM !!!)"

Re: JSON Schema bundling formalised

#126

Post by dolmen »

sorokod wrote: post #6

Would be good if there was a clear statement about who the authors are and what makes their content authorative.

json-schema.org is the place where the JSON Schema working group at IETF publishes its work.

They also publish on IETF infrastructure. Example: https://datatracker.ietf.org/doc/html/draft-bhutton-json-sch...

Ben Hutton who is the author of the blog post is also the editor of the latest publlished IETF drafts. https://datatracker.ietf.org/person/ben@jsonschema.dev

Do you need some more authoritative source?

Re: JSON Schema bundling formalised

#127

Post by mstade »

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 schemas in a javascript environment. (I'm not affiliated with Ajv in any way, just happy with it.)

Working without a schema is much faster when getting started, obviously, but once things solidify in my experience a schema will help more than it costs and excellent tooling goes a long way in easing that transition from schema-less POCs to stable high quality implementations.

[1]: https://ajv.js.org

Re: JSON Schema bundling formalised

#128

Post by lolive »

noworld wrote: post #74
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…

So what makes JSON Schema better is that nobody will "build an enormous ecosystem of tools on top" of it?

It depends the (complexity of the) JSON schema to mainpulate.

Re: JSON Schema bundling formalised

#129

Post by dolmen »

run-types wrote: post #97

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…

The point of JSON Schema is to have a common format independant of the programming language to ease interoperability.

Re: JSON Schema bundling formalised

#130

Post by xienze »

paulddraper wrote: post #79
m_st wrote: post #66

Earlier quoted context omitted.

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.

And that's the issue. SOAP isn't some nice standardized language-agnostic API layer. SOAP is .NET/Visual Studio RPC. (Not technically, but in practice, due to its complexity.) And hey, great for you. But a lot of people want APIs to be broadly compatible.

> SOAP isn't some nice standardized language-agnostic API layer.

What? Of course it is (well, it's a messaging protocol). Where on earth did you get the idea that it's some Microsoft-only proprietary technology?

Post reply on HN