I've worked with Will on a large XML based system. I'll try to briefly describe our workflow. Our company created reference books. Those books ended up both as printed books and as HTML in a web application service people could subscribe too. Various people would create the content, some in WYSIWIG editors, others editing raw html to tag content to give it structure, and tools that fall somewhat in between. XML tags and annotations can do things like indicate where the title is, sub headings, links to other books or content. etc etc.
This annotation structure not only lets us transform the xml into HTML that resembles the physical book via CSS, but also lets us search the content with awareness of what the content is. Simple example, if a search term appears in a title give it more weight.
When a book is done the XML goes off to a printer to become a book, AND into our XML database. A nice feature of which is a lot of our content is in the DB as XML, you ask for a book page and the DB returns the HTML for the page, backend just forwards that HTML to the browser which displays it. ZERO parsing/transformation anywhere once the DB sends it! Just fling the payload at the browser. Super cool at times.
Anyway we all work with these formats differently, some of us never touch the json and xml, some of us only tweak values in config files. Those of us who work with it like that, the only differences between XML and JSON are "how nice are the serialization apis and how fast are they? how big is the payload?"
But when working WITH the format directly there can be more meaningful differences. And the tools that actually exist for the things you are doing may push you towards one format or the other, even if in principle it wouldn't have really mattered.
note: I keep mixing tenses here but this was all in the past, we got bought, don't do any of this anymore!
Gotcha, I was thinking more in terms of JSON as a serialization / interchange format (given the OP), rather than use cases such as the one you describe above.
To clarify: no, I do not believe that JSON is universally better than XML. I believe JSON is better than XML for the majority of use cases where people are currently using JSON today, esp. as an interchange format.
Please keep your patronizing comment to yourself, or add some arguments to it.
JSON's spec is simpler, and the data are more compact. There are a ton of extremely fast parsers, as well as stream parsers. Many languages support JSON natively making it extra easy for interoperability.
Pretty sure that was in response to you making assumptions about their experience, not as an answer to the question about what specifically makes them think that, which you only asked afterwards.
This whole chain of comments is a good example of why responding with a dismissive short comment isn't a good idea, even if it feels good to send in the moment.
With equal samples in the two formats, JSON wins on readability. I can draw up bad examples in both. Since you've seen back JSON already, I give you real-world XML (I actually saw this example, yes), describing whether a structure has a roof, or not.
(Normally, exactly one of either the <true> or <false> tags should have a "1", and the other a "0". Normally.)
(The really horrible thing was that there were … I don't want to call them "reasons" because that's a strong word, so let's say "cause and effect" that led to this format… and once you came to know them, you "understood", in a sort of horrible sense, the format. But give me a JSON bool any day over it.)
You don’t state your reasons for this very bad XML, but your comment suggests to the uninformed that XML doesn’t support Boolean types, which isn’t the case.
XML doesn’t support booleans. XML Schema, one of several separate add-on schema languages for XML does, but comparing XML + XML Schema to bare JSON does not make sense.
XML Schema isn't only for validating XML post-hoc, as you suggest. The point is that if you are using XML, it doesn't make sense to invent arbitrary solutions when there is already first class support in standardized toolchains. Comparing the markup specs, specifically, is an unreasonably narrow comparison. The discussion is about "using XML" and "using JSON", and the environments in which they're used are at least as important as the specs, independently.
If you are somehow in an environment where you are working with data nominally encoded according to XML spec, yet unable to leverage any other parts of the standard XML ecosystem, then I would certainly agree that XML is a bad choice!
This. Once a document is big or complex enough, the benefit of human readability fades away and you are left with a brittle and very slow serialization format.
