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

181–190 of 252 posts

Re: JSON vs. XML

#181

Post by n0w »

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…

Oh, hey. That's cool. I hadn't realised Douglas Crawford worked on E. I haven't actually looked but I wonder who else participated?

E had some really cool ideas, it's sad that it doesn't seem to be that well known!

Re: JSON vs. XML

#182

Post by Sohcahtoa82 »

treis wrote: post #141
dragonwriter wrote: post #103

Earlier quoted context omitted.

Okay, so the point at which you need to adopt a schema language in toy examples is earlier with JSON, but in most practical cases you’ll want to do that in either JSON or XML (because, even if you are only using built-in types, you’ll still want to communicate the shape), so this objection is kind of meaningless.

Well, no. Because JSON & by extension OpenAPI lack a Date type you can't easily add validations about dates to those schemas. Like you can't say this particular date must be in the past in an OpenAPI spec because it has no concept of a date. The best you can do is a regex on the strings you call dates but that falls apart pretty quick.

> Like you can't say this particular date must be in the past in an OpenAPI spec because it has no concept of a date.

I don't get these types of arguments.

There's zero reason you can't write code that parses a date in an expected format (and throws an error if the date is formatted incorrectly) and then checks that the date is in the past.

Yes, it does mean you'll spend time writing more code (You know, the job you're being paid to do?), and it would be nice if your data format supported such automatic checking functionality out of the box, but to say "It can't be done!" is just plain silly.

Re: JSON vs. XML

#183

Post by datavirtue »

ssdspoimdsjvv wrote: post #98
fatnoah wrote: post #16

Earlier quoted context omitted.

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

Nowadays you have the same type of tools, only for YAML. Not sure if that's so much better.

YAML can die in a fire

Re: JSON vs. XML

#184

Post by hot_gril »

taeric wrote: post #167
hot_gril wrote: post #147

Earlier quoted context omitted.

Writing that JSON example by hand wasn't tedious. The XML example was, and the result is unreadable. It's important to be able to debug things easily. I'm going to manually type JSON when I'm testing an API, and I'm going to read the response. If you absolutely don't care about human interface, no reason to use XML either. It's meant to be more verbose. The XML tags will often dominate the size of the payload with th…

Not wrong, but also probably not really indicative of problems or actual use. And while I will be manually typing some data to go into an api for testing, I'm far more likely to by typing it in a thing that is was looser in what it accepts than a json document. Literally today just using dicts in python. And even then, my debugging is dominated by mistakes in data entry there. Also, I see you took it to be a full on…

JSON vs XML isn't going to make or break your project. But why would you use XML for data interchange. It makes sense for things like HTML where you're writing a document, but otherwise, it's usually just a needless burden.

Like, if I were there when XMPP was created, yes I would have insisted on JSON. XML was a plainly bad choice. Edit: Oh, JSON didn't exist until a little later. Maybe something similar did.

Re: JSON vs. XML

#185

Post by Sohcahtoa82 »

user3939382 wrote: post #13

If it's not obvious, the issue is that standardizing a data format is going to have trade offs. Interoperability, leveraging tooling universally so all effort is going in the same direction, awesome. The problem is that some uses cases for the format are going to be insanely complex, which will make the standard and tools unnecessarily complex for the simple cases. JSON is simpler and easier for many cases, but then…

> you're going to end up translating JSONXML which isn't fun.

Not fun? It's not even possible in the general sense.

If you have XML that looks like:

    
       
           cheese
How would you convert that to JSON without knowing how the JSON consuming application expects it to be formatted? Where do you put the "breakfast" and "count" attributes?

You'd need to manually write a translator for each potential translation.

Re: JSON vs. XML

#186

Post by Sohcahtoa82 »

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

Re: JSON vs. XML

#187

Post by emn13 »

hot_gril wrote: post #147
taeric wrote: post #146

Earlier quoted context omitted.

If we are complaining about the closing tags, might as well add that embedding newlines or quotes into JSON is less than pleasant. Which is to say, this feels a touch of a non-issue. Yes, writing it by hand can get tedious, but that is true of any and every format. Is why you will almost certainly reach for other formats if doing a long list of data. And each and every one of them will fail for some form of input in…

Writing that JSON example by hand wasn't tedious. The XML example was, and the result is unreadable. It's important to be able to debug things easily. I'm going to manually type JSON when I'm testing an API, and I'm going to read the response. If you absolutely don't care about human interface, no reason to use XML either. It's meant to be more verbose. The XML tags will often dominate the size of the payload with th…

Who "question":"Who",

To me, this does not seem like a win that's worth much, especially since it's likely to shrink considerably even with naive fast compression.

Furthermore, as messages grow in size, the explicitly named closing tag actually kind of starts helping.

Both of these syntaxes have their annoying quirks, for sure, and I understand you really dislike the closing tag; that clearly doesn't bother many people.

But regardless of personal preference, I'm really skeptical any of this really explains json's relentless path to replace (most) xml. Other reasons, such as the extreme wordiness some xml apis chose, the poor implementation of namespaces, the problems with embedding arbitrary data (in particularly control characters), the inconsistency between attributes and elements, the lack of support for numbers, the lack of (conventional) support for key-value pairs - all of these surely played a much greater role than a fairly limited syntax issue.

And it's not even like json is without impractical quirks; lack of comments, the ban on trailing commas, and the need for quotes in object-keys spring to mind. Yet those don't mean json is likely to die out soon - even though even javascript itself from which it is derived doesn't suffer from those (anymore)!

Re: JSON vs. XML

#188

Post by Sohcahtoa82 »

slaymaker1907 wrote: post #118

My biggest gripe with XML is that it can't represent arbitrary strings easily. Even in the latest versions of XML, you can't easily serialize strings with embedded nulls since it is forbidden by the spec to even use something like "�". XML 1.0 was even worse since it doesn't allow any characters which require surrogate pairs under UTF-16. Instead, the spec writers apparently expect devs to come up with their own e…

If I had to deal with strings that XML won't allow, I'd probably just rely on encoding the data in Base64 before throwing it into the XML.

A human won't be able to read it (Unless you're crazy and have learned to read Base64), but the application still can easily. You'll just have to add a Base64 translation step before/after serialization/deserialization.

Re: JSON vs. XML

#189

Post by andyjohnson0 »

hot_gril wrote: post #142
andyjohnson0 wrote: post #126

Earlier quoted context omitted.

Care to elaborate?

Every key is written twice, for opening and closing. Keys can be duplicated, and in fact that's what you have to do if you want a simple list. There aren't numeric types, so you have to parse strings. It also looks horrible. Led Zeppelin II Led Zeppelin 999 La Brise Arax 999 or Led Zeppelin II Led Zeppelin 999 La Brise Arax 999 vs something like [ {"title": "Led Zeppelin II", "artist": "Led Zeppelin", "price": 999},…

Thanks. I get your point about the close element including the tag name - but that's the kind of detail I leave to the serialisation library, in the same way that the close scope token in json is different to the start scope token.

As for "looks horrible"... well yeah, I always feel that xml looks "spikey" somehow. But I've been programming in curly-brace languages for 30+ years and I still find json harder to read than xml: I think my brain tries to interpret it as code, not data. I find xml easier to read (even when its unformatted) precisely because the close-tokens kind of document what element they're closing.

Each to their own I guess. At least we're not stuck using ASN1.

Re: JSON vs. XML

#190

Post by treis »

Sohcahtoa82 wrote: post #182
treis wrote: post #141

Earlier quoted context omitted.

Well, no. Because JSON & by extension OpenAPI lack a Date type you can't easily add validations about dates to those schemas. Like you can't say this particular date must be in the past in an OpenAPI spec because it has no concept of a date. The best you can do is a regex on the strings you call dates but that falls apart pretty quick.

> Like you can't say this particular date must be in the past in an OpenAPI spec because it has no concept of a date. I don't get these types of arguments. There's zero reason you can't write code that parses a date in an expected format (and throws an error if the date is formatted incorrectly) and then checks that the date is in the past. Yes, it does mean you'll spend time writing more code (You know, the job you'…

> "It can't be done!" is just plain silly

It's a good thing I didn't say that.

>Yes, it does mean you'll spend time writing more code

The whole point of WSDLs and OpenAPI is to minimize the amount of time it takes to consume your API. Saying you have to write more code is highlighting the shortcomings of OpenAPI at doing the only thing it's built to do. Which is why companies have largely punted on providing OpenAPI specs in favor of maintaining libraries in a handful of popular languages.

Post reply on HN