I bought one of the first books about XML, read it cover to cover; started writing my own parsers and generators, designed a custom XML protocol for a network server at work. Then I had to live through the whole SOAP-drama, and Java EE; and ended up promising myself to never touch it again. It has too many degrees of freedom for its own good, the C++ of data formats. JSON is in many ways the other end of the spectrum…
JSON vs. XML
221–230 of 252 posts
Re: JSON vs. XML
#222What if I hate both formats? XML is overly verbose, while JSON isn't specific enough or precise enough for a lot of my needs. - This message brought to you by TOML gang
Re: JSON vs. XML
#223Earlier quoted context omitted.
What specifically about XML means it can be read/written "stupidly fast"? It's still a text bound serialization format, you still have to parse a tree for it. Is it just particularly mature libraries?
It is primarily mature libraries, but also XML is more straightforward to parse, because there are not many data types and tags makes it very deterministic. By "stupidly fast", I mean I can read a 120K XML file, parse it, create the objects which generated from that file definition under 2ms. The library I use (RapidXML [0]) can parse the file almost with the same time cost of running strlen() on the same file. That'…
Being a maintainer of the fastest XML library for Rust, I strongly disagree that XML is inherently fast to parse, and I question any such claim which comes with no evidence. Especially when it has remained unchanged on their page since (at least) 2008 [0]. Have you actually tested that claim or are you taking it at face value?
IME the XML spec is so complex that you either end up with a slow but compliant parser or a fast one that doesn't implement the spec completely.
JSON, unlike XML, is minimal enough that writing an entire compliant parser with SIMD intrinsics [1] is actually practically feasible. That library claims 3 GBps parsing speed, which could theoretically process your 120kb of data in 1/25000th of a second instead of 2/1000ths of a second.
I would wager that JSON is faster to parse, on balance.
[0] https://web.archive.org/web/20080209172554/https://rapidxml....
Re: JSON vs. XML
#224Earlier quoted context omitted.
I first touched XSLT in 2010. I appreciated what it could do, but it was painful to work with due to poor documentation and tooling. This has only gotten worse by comparison with alternatives. You can still do XSLT in the browser. You can serve arbitrary XML and transform it. As an example, Atom feeds on my website (such as https://chrismorgan.info/blog/tags/meta/feed.xml >) render just fine in all mainstream browser…
I think out of the box, browsers can only do xslt 1; but Saxon offers a JS version of their engine that does xslt 3.0 and is free (as in beer): https://www.saxonica.com/saxon-js/index.xml
It’s actually worse than XSLT 1.0 due to inconsistencies and incompletenesses. For example, Firefox doesn’t respect , but uses an XML parser on the transformed result regardless; and doesn’t support disable-output-escaping. I wanted these for my Atom stylesheet (for and the likes; instead I had to emit serialised HTML and decode it in JavaScript, though with difficulty I could have done feature-detection to skip that step if disable-output-escaping worked).
Even perfunctory probing shows fairly serious problems in Firefox (where Chromium is consistently much better, in this specific area). I could file quite a few bugs in short order (e.g. these mentioned, bad document.contentType values, not working properly), but I don’t think there’s any interest in fixing things.
(I wrote this comment as much for my own future reference as anything else. XML/HTML polyglot stuff makes things decidedly messy at times.)
Re: JSON vs. XML
#225I'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.
It's an ugly tool. People generally hate ugly tools
Re: JSON vs. XML
#226Re: JSON vs. XML
#227Earlier 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…
> If you are describing a graph, neither have broadly accepted standards so you are kinda on your own
Relational databases can describe most graphs, but they rarely ever have a great text format.
Re: JSON vs. XML
#228Earlier 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…
Yeah, now express this in JSON:
JSON example:
[
{"title": "Led Zeppelin II", "artist": "Led Zeppelin", "price": 999},
{"title": "La Brise", "artist": "Arax", "price": 999},
]
Source: click here!
Use the right tool for the job.
Re: JSON vs. XML
#229Earlier quoted context omitted.
Yes, though many languages have lenient parsers. Most browser parsers, for example, will probably only be lenient if parsing "HTML." new XMLSerializer().serializeToString(new DOMParser().parseFromString(" hello ", "text/html")) The above in my console does as expected there. And again, entities are a very dangerous part of XML and friends. You are correct that if you tell it that that is xml, the browser will throw i…
per specifications, json parsing is not lenient, html parsing is lenient
To be pedantic, html parsing is not lenient, it is unambiguously specified.
Re: JSON vs. XML
#230Earlier 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…
And CSV for tabular data!