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

JSON vs. XML

corecursive.com

Post reply on HN
Print view View original

211–220 of 252 posts

Re: JSON vs. XML

#211

Post by hajile »

irrational wrote: post #162
Zamicol wrote: post #46

From another interview: >The best thing we can do today to JavaScript is to retire it. Twenty years ago, I was one of the few advocates for JavaScript. Its cobbling together of nested functions and dynamic objects was brilliant. I spent a decade trying to correct its flaws. I had a minor success with ES5. But since then, there has been strong interest in further bloating the language instead of making it better. So J…

The biggest impedances I see to replacing JS are: 1. You've got to keep JS around for backwards compatibility for the billions of websites already using it. 2. You will need to two engine teams, one to maintain JS and one for the new language. 3. Now you have a whole new vector for security issues. You've made the threat surface much broader. So, you will probably need to hire additional people. 4. You need to coordi…

That depends on the language you choose.

If we went to a scheme dialect as originally intended, we could have just ONE language for all the things.

Legacy JS? Just compile it into Scheme and run it.

HTML? Use S-expressions and support legacy HTML syntax by compiling it into them. Now you get all the power people want from template languages, but baked right into main language itself.

CSS? No more weirdness like adding sin() or calc() to make up for shortcomings. Once again, you get the power of the full Scheme language right there.

Re: JSON vs. XML

#212

Post by XorNot »

orthoxerox wrote: post #137
Seanny123 wrote: post #48

Earlier quoted context omitted.

What are some examples of the "enormous tool stack" required for XML? I ask, because I came into software development after everyone adopted JSON. When I do need to parse XML, there was a library I could use, although I will admit that needing xpath was a bit annoying.

If your XML is written the way people write JSON, then the stack isn't enormous. But XML is usually wrapped in layers of additional complexity. SOAP envelopes and namespaces they require, XSLT that someone invariably used to write an XML transformer, etc.

Also broken parsers. So many broken parsers. Honestly this is what keeps JSON going: the parser was simple because the language was simple, and as a result any JSON you got basically worked the same way.

Not so with XML: all the parsers were insanely complex with the namespacing and whatnot feature support and possible external URLs and everything else...and as a result however no XML library was ever adequate to interface with anything. On multiple occasions generally the best way to build XML for something was to take a working copy, and then glue text together so you would exactly replicate whatever that specific application wanted, rather then trying to use anyone's library for it.

Re: JSON vs. XML

#213

Post by taeric »

preseinger wrote: post #210
taeric wrote: post #207

Earlier quoted context omitted.

Right, and amusingly, more than a few json parsers are very lenient in this. That or folks abandon ship fairly quickly and go for another spec that is far more friendly.

well json definitely does not accept `{'test':'value'}` as valid input any parser that behaves otherwise is pretty clearly buggy json has many problems but parsing ambiguity is not really one of them

Me thinks you have never looked at the field. I'd as soon declare csv is an error free format. Only true if you ignore the proliferation of applications that get it wrong. In subtle ways, often. Still wrong.

Re: JSON vs. XML

#214

Post by maple3142 »

Sohcahtoa82 wrote: post #186
maple3142 wrote: post #161

One of the reason to prefer JSON over XML is that you can reasonably parse an untrusted JSON using default configuration without getting yourself pwned. A lot of XML processing libraries still support external entities by default that you have to disable them manually: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_...

> you can reasonably parse an untrusted JSON using default configuration without getting yourself pwned. If only this were true. https://medium.com/r3d-buck3t/insecure-deserialization-with-...

I know that one, but I think JSON.NET is to blame for this because it decide to take `$type` and other fields and apply some reflection magic on it. It isn't really different from evaling a random json field in your own business code. A lot of sane json implementation also don't do this too, like `JSON.parse` `json.loads` `json.Unmarshal`...

On the other way, XML External Entity is a part of XML standard, so any standard compliant XML implementation have to support it. This is why XXE attack applies to many languages.

Re: JSON vs. XML

#215

Post by preseinger »

taeric wrote: post #213
preseinger wrote: post #210

Earlier quoted context omitted.

well json definitely does not accept `{'test':'value'}` as valid input any parser that behaves otherwise is pretty clearly buggy json has many problems but parsing ambiguity is not really one of them

Me thinks you have never looked at the field. I'd as soon declare csv is an error free format. Only true if you ignore the proliferation of applications that get it wrong. In subtle ways, often. Still wrong.

csv is wildly ambiguous, to the frustration of ~every data science engineer in industry

json is not

show me an application that parses `{'a':'b'}` as valid JSON, i'm actually interested, probably there are some which exist, but there is no ambiguity about those applications being wrong

Re: JSON vs. XML

#216

Post by taeric »

preseinger wrote: post #215
taeric wrote: post #213

Earlier quoted context omitted.

Me thinks you have never looked at the field. I'd as soon declare csv is an error free format. Only true if you ignore the proliferation of applications that get it wrong. In subtle ways, often. Still wrong.

csv is wildly ambiguous, to the frustration of ~every data science engineer in industry json is not show me an application that parses `{'a':'b'}` as valid JSON, i'm actually interested, probably there are some which exist, but there is no ambiguity about those applications being wrong

https://news.ycombinator.com/item?id=12796556

Re: JSON vs. XML

#217

Post by asdfafe »

IshKebab wrote: post #97
dvh wrote: post #15

For me 3 killer features of JSON are: 1. Parsing JSON doesn't require adding new firewall rules 2. There are no comments, so nobody will try to invent their own meta format or annotations in comments and instead they will put data in the JSON as they should 3. (When compared to JS) someone finally had the balls and picked one type of quotes, this makes making parser so much simpler.

Not supporting comments in JSON was a huge mistake. Yes I'm sure that someone, somewhere has once added comment directives to a file that caused issues. But that's such a rare problem compared to the very real and damaging and annoying problem of not being able to add comments to config files (hello package.json) that it's definitely the wrong choice. XML supports comments and I have not seen a single use of comment…

directives can just be put in adjacent fields anyways

Re: JSON vs. XML

#218

Post by dwaite »

stickfigure wrote: post #105
bambax wrote: post #90

Earlier quoted context omitted.

> I had to maintain a system once where a major part of it was XSLT Every time the topic comes up I feel the need to say that I loved XSLT. It was so nice. XML frankly was kind of simple, too. It had elements and attributes and that was it. And it had xpath, which offered, among other things, a parent axis, so you could walk the node tree upwards. In JSON you can't get to the parent from the child. And walking down a…

I would describe it something like: XML is great as a document format, but shitty as an RPC format. JSON is vice-versa. Web developers spend a lot of time with JSON as an RPC format, so they tend to put it on a pedestal. But try keeping your recipe collection structured in JSON text files and the pain will start immediately. YAML is even worse. XSLT was (and still is) great for transforming documents . Want that reci…

Yep:

- If you are describing hierarchal data, JSON is great

- If you are describing text with markup, especially extensible markup, for machine generation and consumption, XML is great.

- If you are describing a graph, neither have broadly accepted standards so you are kinda on your own.

Depending on your requirements, a recipe collection might be better in XML or in a flavor of markdown. A comprehensive data schema and software support for recipes could be challenging/limiting, compared to marked-up text.

Re: JSON vs. XML

#219

Post by preseinger »

taeric wrote: post #216
preseinger wrote: post #215

Earlier quoted context omitted.

csv is wildly ambiguous, to the frustration of ~every data science engineer in industry json is not show me an application that parses `{'a':'b'}` as valid JSON, i'm actually interested, probably there are some which exist, but there is no ambiguity about those applications being wrong

https://news.ycombinator.com/item?id=12796556

fun doc! it lists many of the undefined behaviors of the spec, and many of the problems in common parsers

afaict none of them permit keys or value strings to be expressed with single quotes

Re: JSON vs. XML

#220

Post by rezaprima »

fatnoah wrote: post #16
adamgordonbell wrote: post #3

This quote is funny: Douglas: The first time I saw JavaScript when it was first announced in 1995, I thought it was the stupidest thing I’d ever seen. And partly why I thought that was because they were lying about what it was. A bigger more interesting thing though is how his company failed, in part, because they used hand-rolled JSON for messaging. Douglas: And some of our customers were confused and said, “Well, w…

> I started my career during peak XML crazy and while I liked parts of it at the time, the number of things it was used for was quite insane. I had to maintain a system once where a major part of it was XSLT, when could have just been a simple imperative algo with some config settings. Same here. XML was going to save the world! Remember XML data islands with data embedded in page source and displayed via XSLT? The c…

I do just like this with json. Creating api blueprints.
Post reply on HN