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

231–240 of 252 posts

Re: JSON vs. XML

#231

Post by bmarkovic »

treis wrote: post #99
halostatue wrote: post #62

Earlier quoted context omitted.

Every JSON schema is also a potential DSL that reinvents everything. Yes, there seems to be some convergence on things, but object arrays in XML aren’t really any more complex than object arrays in JSON — there just might be multiple ways to represent them. For this JSON: { "part_numbers": [1, 2, 3, 4, 5] } You have two main ways to represent these in XML: 1 2 3 4 5 1 2 3 4 5 Is this better than JSON? No, not particu…

Where XML shines is when you pass more complex data types than numbers and strings. If you repeated your example for an array of dates, as an example, strictly speaking you can't even generate the JSON. We'd first have to agree on what string representation of a date we want to use. For XML it's built into the spec.

In JSON the de facto standard for datetime is (because of JavaScript) very much the Unix msec timestamp (which is always in UTC) so while it's not hardcoded in spec you basically need to be an idiot not to do it like that, and removes one huge headache of XML dates which is timezones.

Re: JSON vs. XML

#232

Post by sixbrx »

hot_gril wrote: post #144
wongarsu wrote: post #39

Earlier quoted context omitted.

That depends on what you want it to be. For a data interchange format, having no comments is arguably a strength. For a config file format, having no comments is a big weakness.

Just do { "someSetting": true "comment": "TODO change to false when ready" } Though really text-based protobufs are better for config.

Problems are that some tools will rewrite the file and reorder the "comment" away from what it's meant to comment on. Also might complain the "comment" item isn't expected there. I seem to remember package.json suffering from both of these under the control of npm.

Re: JSON vs. XML

#233

Post by stickfigure »

dwaite wrote: post #218
stickfigure wrote: post #105

Earlier quoted context omitted.

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…

Markdown (like HTML) offers formatting structure, not semantic structure. Maybe you want to query for recipes that can be made in under an hour, or that contain orange as an ingredient (as opposed to merely a serving suggestion in an orange bowl). A proper XML (or even JSON or YAML) structure would enable this, Markdown does not.

You can pretty easily translate XML to Markdown using XSLT, though.

I don't think hierarchal structure is the differentiator; recipes and web pages are hierarchical and they'd still be hell in JSON. XML handles hierarchy just fine. I think the differentiator is whether your content is a document, that is, composed significantly of multiline text. Multiline text in a JSON file tends to be human-hostile, but we're all comfortable editing eg html.

Re: JSON vs. XML

#234

Post by stickfigure »

goto11 wrote: post #230
dwaite wrote: post #218

Earlier quoted context omitted.

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 CSV for tabular data!

If only it was more standardized :-(

Re: JSON vs. XML

#235

Post by taeric »

preseinger wrote: post #219
taeric wrote: post #216

Earlier quoted context omitted.

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

Apologies for the, in retrospect, somewhat lazy posting of an article with no comment. I thought that article had a section about how many of them allow single quotes if you don't "enable strict." I am not seeing it on review, though; so either I made that up in my mind, or I'm remembering another article. Either way, apologies.

I did find https://github.com/json5/json5 no a quick search that basically says what I asserted about people just jumping to another standard for things that you hand write. I was probably also thinking heavily about python's dict syntax. (And I confess, I still don't know when to use single versus double quotes in python...)

Re: JSON vs. XML

#236

Post by ledauphin »

andyjohnson0 wrote: post #127

I'll never understand the hating that xml tends to get around here. Choose the right tool for the job at hand. Sometimes json is the right choice, sometimes xml is. Not everything is a webapp.

based on the overwhelming majority of the top 30 comments, i think you should feel comforted.

Re: JSON vs. XML

#237

Post by throwawaymaths »

sanitycheck wrote: post #18

I have huge respect for Doug Crockford, and I never imagined I would disagree with him. However I think by now we've seen that a lot of that "unnecessary" XML complexity was not, in fact, entirely unnecessary. These days we use JSON for everything, but now we've got JSON Schema, Swagger/OpenAPI, Zod, etc etc. It's not really simpler and there's a lot of manual work - we might as well be using XML, XSD & SOAP/WSDL.

OpenAPI is complex not because of JSON, but because it's a nearly complete description of http.

Re: JSON vs. XML

#238

Post by hot_gril »

sixbrx wrote: post #232
hot_gril wrote: post #144

Earlier quoted context omitted.

Just do { "someSetting": true "comment": "TODO change to false when ready" } Though really text-based protobufs are better for config.

Problems are that some tools will rewrite the file and reorder the "comment" away from what it's meant to comment on. Also might complain the "comment" item isn't expected there. I seem to remember package.json suffering from both of these under the control of npm.

Yeah it's definitely a limited solution, and I prefer that JSON be kept simple that way. Many package.json-adjacent configs like the Babel stuff can be in .js files, giving you comments and everything.

Re: JSON vs. XML

#239

Post by slaymaker1907 »

taeric wrote: post #179
slaymaker1907 wrote: post #176

Earlier quoted context omitted.

Most languages (C#, Java, Rust, JavaScript, etc.) support nulls in the middle of strings so it can be a security vulnerability if you try to serialize untrusted input to XML. I'd much rather be able to encode anything my input language considers a string and deal with excessive escaping than need to worry about what I'm going to do with inputs that my serialization language cannot support.

I'm curious what the vulnerability is? Also not clear what the null character is. Any links I can follow? And again, if this is your line in the sand, how do you serialize NaN and Infinity in JSON? Edit: Playing with this a bit, I'd actually assume that allowing \0 would be a vulnerability. I was curious how browsers treat it, so I see that parsing to an html document seems to just drop the characters? Fun little rab…

Yeah, that's why I consider it to be a breeding ground for vulnerabilities. People will probably just assume the XML serializer can handle any strings in their language of choice and not handle those edge cases. What I ended up doing for my use case was to encode nulls as "�" but within a CDATA section so it was interpreted literally (choosing ambiguity over omission). The best way would probably be to have some sort of spell element, but there isn't such a thing within the standard. There asi:nil, but that is really indicating something else.

Re: JSON vs. XML

#240

Post by slaymaker1907 »

Sohcahtoa82 wrote: post #188
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.

It's very annoying to do that though since that introduces a bunch of logic in the application and also removes the benefit of being able to read the strings in the XML as a human.
Post reply on HN