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

The rise and rise of JSON (2017)

twobithistory.org

Post reply on HN
Print view View original

21–30 of 107 posts

Re: The rise and rise of JSON (2017)

#21

Post by senozhatsky »

pingec wrote: post #14

I use XSD a lot for XML validation in .net world and better intellisense when writing XML by hand. I was exploring the json world but I could not find a json schema technology that would be as expressive and the tooling around it is much inferior IME. I feel like the technology around schemas (json, xml or anything else) is underrated and not developed enough. And if I wanted to support both json and xml it would be…

> would be nice to have a tool that could translate xml schema to json schema and back.

Hmm, after a quick search I found a bunch of json-to-xml and xml-to-json converters, including libraries. E.g. JSON-Java library [0]. May be same things exist for .Net. Is this what you meant?

[0] https://github.com/stleary/JSON-java

-ss

Re: The rise and rise of JSON (2017)

#22

Post by ubernostrum »

ToFab123 wrote: post #15

So, when do we get a typescript for JSON? You mean a schema like XML has? It looks like typesafe programming languages are on the rise, yet, when it comes to the format used for data exchange we go from typesafe to unstructured. I find that odd.

The counterpoint here is that a lot of the success of JSON was in presenting an alternative to the then-state-of-the-art, which was basically "here's a small mountain of spec documents explaining how you need at least fifty megabytes of metadata spread out over forty-three separate namespaces' worth of elements to safely send a single string key to someone else with XML".

And at the time people insisted JSON could never replace that, because JSON was so underspecified and unsafe. You could maybe get away with it for a couple requests to your puny baby child's "Fisher-Price My First Webservice" toy program, but JSON would instantly and completely fall over the instant any real-world problem presented itself.

Yet here we are all those years later, in a world which largely runs on JSON as a data interchange format.

Or, more concisely, as I wrote in 2006 in response to the Dave Winer piece someone else linked in another comment:

And now here are these kids with their startup companies and their weblogs who are getting data exchange and even things that kind of look like APIs out of… JavaScript arrays? The XML guys are sitting up on the mountaintop like the Grinch, with his pile of stolen presents, wondering how Christmas still managed to happen: it came without specs! It came without hype! It came without angle brackets, envelopes or types!

Re: The rise and rise of JSON (2017)

#23

Post by eridius »

lwansbrough wrote: post #18
pingec wrote: post #14

I use XSD a lot for XML validation in .net world and better intellisense when writing XML by hand. I was exploring the json world but I could not find a json schema technology that would be as expressive and the tooling around it is much inferior IME. I feel like the technology around schemas (json, xml or anything else) is underrated and not developed enough. And if I wanted to support both json and xml it would be…

I’ll pass on any serialization format that is itself vulnerable to RCE.

You can easily create a parser with RCE using just JSON. Just define a simple schema that looks like

  {
    "type": "ObjectName",
    …
  }
The only difference between this and e.g. YAML is YAML has specific syntax for declaring the object type whereas with JSON you need to declare it yourself.

Re: The rise and rise of JSON (2017)

#24

Post by taeric »

blauditore wrote: post #13

It's funny how people often compare JSON and XML, but don't mention one huge difference: XML is "more powerful" because it supports attributes on nodes, while JSON doesn't. So if you want to encode data structure with metadata on nodes (like objects with a type), you'll have to introduce a non-standard workaround. Of course that's often not an issue, but I've run into it in the past. :)

Oddly, attributes do little to actually help you here. What mattered was that xml gave you a language that could describe a valid document. Which, for reasons that actually exist, wasn't necessarily a valid xml document.

That said, the effort to write a valid schema was rather high. And it was sold with the other technologies that were in violation of the anti-fragile spirit of the web. That left us with people wanting something different. JSON was born as much for basically being javascript literals minus functions as it was anything else. Most any other explanation is just someone selling you something.

(Now, attributes did offer a technical way to ignore subsets of the attributes that would be hard to do any other way. But they didn't exactly make it easy, and namespaces did not compose nearly as well as people hoped they would.)

Re: The rise and rise of JSON (2017)

#25

Post by hguhghuff »

ubernostrum wrote: post #22
ToFab123 wrote: post #15

So, when do we get a typescript for JSON? You mean a schema like XML has? It looks like typesafe programming languages are on the rise, yet, when it comes to the format used for data exchange we go from typesafe to unstructured. I find that odd.

The counterpoint here is that a lot of the success of JSON was in presenting an alternative to the then-state-of-the-art, which was basically "here's a small mountain of spec documents explaining how you need at least fifty megabytes of metadata spread out over forty-three separate namespaces' worth of elements to safely send a single string key to someone else with XML". And at the time people insisted JSON could ne…

There’s passion for you.

Re: The rise and rise of JSON (2017)

#26

Post by asavinov »

If we ignore syntactic aspects then the success of JSON is due to one fundamental reason. JSON relies on two structural elements [] and {}, which have very clear semantics of sets (collections) and tuples (combinations), respectively. It is simple, general, natural and consistent.

In comparison, XML also provides two structural elements but they do not have such a nice duality and clarity of interpretation. Here is a very typical example which is more than an anti-pattern:

     
        XML is evil 
        XML considered harmful
Here we see that semantically is a collection while is a tuple (where is an attribute). Yet, they use one and the same structural construct. XML does not enforce the dual semantics of sets and tuples, and therefore XML files are frequently a conceptual mess. The above example is essentially wrong but XML does not care.

Re: The rise and rise of JSON (2017)

#27

Post by donmatito »

ubernostrum wrote: post #22
ToFab123 wrote: post #15

So, when do we get a typescript for JSON? You mean a schema like XML has? It looks like typesafe programming languages are on the rise, yet, when it comes to the format used for data exchange we go from typesafe to unstructured. I find that odd.

The counterpoint here is that a lot of the success of JSON was in presenting an alternative to the then-state-of-the-art, which was basically "here's a small mountain of spec documents explaining how you need at least fifty megabytes of metadata spread out over forty-three separate namespaces' worth of elements to safely send a single string key to someone else with XML". And at the time people insisted JSON could ne…

Or, "worse is better"

Re: The rise and rise of JSON (2017)

#28

Post by seanwilson »

ToFab123 wrote: post #15

So, when do we get a typescript for JSON? You mean a schema like XML has? It looks like typesafe programming languages are on the rise, yet, when it comes to the format used for data exchange we go from typesafe to unstructured. I find that odd.

You've got a point. I really like TypeScript but I haven't found a nice way yet to process the results of APIs that return JSON in a type safe manner. I'm surprised there isn't a standard way to do this yet.

Re: The rise and rise of JSON (2017)

#29

Post by tannhaeuser »

blauditore wrote: post #13

It's funny how people often compare JSON and XML, but don't mention one huge difference: XML is "more powerful" because it supports attributes on nodes, while JSON doesn't. So if you want to encode data structure with metadata on nodes (like objects with a type), you'll have to introduce a non-standard workaround. Of course that's often not an issue, but I've run into it in the past. :)

It's funny how people often compare JSON and XML, but fail to see that XML/SGML is for document data (like whole web pages) whereas JSON is a clever reuse of JavaScript object literal syntax.

Re: The rise and rise of JSON (2017)

#30

Post by ubernostrum »

blauditore wrote: post #13

It's funny how people often compare JSON and XML, but don't mention one huge difference: XML is "more powerful" because it supports attributes on nodes, while JSON doesn't. So if you want to encode data structure with metadata on nodes (like objects with a type), you'll have to introduce a non-standard workaround. Of course that's often not an issue, but I've run into it in the past. :)

http://www.flightlab.com/~joe/sgml/faq-not.txt

Q. I'm designing my first DTD. Should I use elements or attributes to store data?

A. Of course. What else would you use?

Q. What is the usual way to choose between using attributes and children?

[Update from David Carlisle:]

In England, the normal method is to flip a coin in the air and call heads it's attributes, tails it's children.

Unfortunately I'm not sure what to suggest in other countries where you can't guarantee having the Queen's head on one side of every coin.

Post reply on HN