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

131–140 of 188 posts

Re: JSON Schema bundling formalised

#131

Post by radomir_cernoch »

oaiey wrote: post #103
staticassertion wrote: post #88

Earlier quoted context omitted.

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

Parsing XML is just grammar like JSON is ... that is not more or less difficult. JavaScript just has a built-in JSON Parser (which translate JSON into JavaScript object). As a consequence, JSON in JavaScript is super easy. Using XML is medium-hard. In .NET using XML or JSON is easy (not super easy). In C++ using XML or JSON is medium-hard. Do not know the state of the art for Go, Rust, Java, ... As a consequence, JSO…

In can't agree more.

In Java, there's the JAXB ”parser“ which translates an XML schema into (mostly) straightforward classes. Correct initial setup is the only hard part.

Re: JSON Schema bundling formalised

#132

Post by move-on-by »

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…

I've never seen runtypes, but I've seen io-ts [1]. Are you aware of the pros/cons between them?

[1] https://gcanti.github.io/io-ts/

Re: JSON Schema bundling formalised

#133

Post by espadrine »

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.

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?

Re: JSON Schema bundling formalised

#134

Post by beardyw »

segphault wrote: post #60

The way $ref resolution works is hideously complicated, to the point where many JSON Schema implementations just don't even bother supporting external $refs. It really should be a totally separate concern from validation, especially since how you store and compose schemas may end up being specific to a given use case.

Much as I value JSON Schema, building a composite schema, to use and reuse parts, can easily hit a brick wall. I often end up building each schema programmatically and exporting to JSON. Could do better.

Re: JSON Schema bundling formalised

#135

Post by sorokod »

dolmen wrote: post #126
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?

Sounds like a candidate for an "About us" section of the website.

Re: JSON Schema bundling formalised

#136

Post by streamofdigits »

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 to JSON-ify the XML stack, essentially focusing on appearances and preserving the substance (a bit like the JSON-LD approach)

In the end of the day these are frameworks for public data / metadata exchange and removing these frictions would be enormously beneficial to everybody...

Re: JSON Schema bundling formalised

#137

Post by oefrha »

dolmen wrote: post #126
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?

> https://datatracker.ietf.org/doc/html/draft-bhutton-json-sch...

That's an expired draft on the informational track. Informational track isn't supposed to be authoritative; drafts even less, let alone expired drafts. Having submitted an Internet-Draft to IETF is an indicator of seriousness, not authority, unless you get it approved on the standards track.

Re: JSON Schema bundling formalised

#138

Post by Jenk »

vultour wrote: post #40
Jenk wrote: post #37

Earlier quoted context omitted.

Do you prohibit the use of VSCode in your workplace? Anyone using that is using jsonschema. It's built into the applicatoin for its settings and configuration files. Plugins and extensions use it to manage their own config _and_ as validation for the editor's api.

Your editor has nothing to do with your product. People use PyCharm to write Python yet would "laugh out" anyone who suggests to start writing Java.

So vscode product team should laugh at themselves?

Do you get how ridiculous GGP is now?

Re: JSON Schema bundling formalised

#139

Post by andyjohnson0 »

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.

This may be true, but they also can't resist it's temptation.

As long as we build tools that are composable, developers will continue to build complexity on top of them. I fear that json's fate is sealed.

Re: JSON Schema bundling formalised

#140

Post by theamk »

oaiey wrote: post #108
dolmen wrote: post #93

Earlier quoted context omitted.

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

Verbosity is not a thing. We read HTML all the time. Parser writing and dumping of data is equally complex for both JSON and XML. The only difference is that in JavaScript JSON is so much simpler due to the dynamic nature of the language and the core library. Out-of-the-box XML parsing in JS is just stone-age. Compare that to .NET System.Xml.XDocument and Newtonsoft.Json, then you can see the simplicity how an API co…

> Parser writing and dumping of data is equally complex for both JSON and XML.

Strongly disagree. Sure, you can make XML which is easy to parse, but parsing arbitrary XML is hard. Namespaces (and their short prefixes), and custom entities are something that fly in my face any time I use XML but simply do not exist in JSON.

Dumping is usually OK but again, I've seen XML libraries replace short namespace prefixes with full URLs when dumping, making simple documents unreadable.

Post reply on HN