9 ms·

XML vs JSON is such a fascinating topic, a clash of different approaches, academic vs practical might be one way of describing it but I'm sure there's many othe

• college_physics 4y ago
  > Are there any good books or essays on it? That would be a really good resource. I mean, anybody who has worked remotely with web technologies has an opinion about this topic but it would be interesting to compile an objective knowledge base and interpretation of why things evolved this way.
• innocentoldguy 4y ago
  I despise XML, not because it was a bad idea, but because of all the bad ways I've seen people use it. For example, I used to work at an ed-tech company that bought bubble test questions from Pearson, who provided their data in HUGE XML documents. If I remember correctly, they would do things like splitting the sentences of the test questions up so half the question was a tag attribute and the other half was an element. So, instead of just parsing questions, we'd have to parse them and then stitch them back together to make complete sentences. They did that with the answers too, I believe. So weird. The JSON format makes it harder to abuse data like my example above and it is a lot easier to parse, so I'd reach for it before XML any day.
  • Thiez 4y ago
    Sounds like something that XSLT could have solved. When in doubt use more XML.
• magicalhippo 4y ago
  In a sense though the circle has been closed. With the latest JSON Schema spec, we were able to do a 1:1 mapping between our XSD's and JSON Schema, so now we can accept JSON as well as XMLs. For small messages though I agree JSON is smoother.
  • didntreadarticl 4y ago
    Whenever I hear people talk about JSON schema spec it reminds me of XML in the 90s.
    • oaiey 4y ago
      Maybe not a popular thing to say: A schema capability is needed. You want to verify input. You want to contract among partners. You want to Intellisense something in a code editor. And is schema languages a complicated beast: Hell yes. Do we need it nevertheless: Yes
• quickthrower2 4y ago
  XML has a unique spot in the intersection of payload and human crafted file. JSON is something I see as payload-only really. And YAML etc are human-craft only. One thing I would change in XML is that closing a tag should not need to specify the name. <> should close any tag. It would make editing a bit easier and save a byte or two.
  • bazoom42 4y ago
    SGML allowed you to minimize a closing tag. And HTML supported this in theory, although mainstream browsers never supported it. XML went for a syntax with fewer options because the complexity of SGML was considered a hinderance to its adoption.
    • ElectricalUnion 4y ago
      SGML is also the reason why a HTML parser is often much more complex that a xml parser, even thought modern html is no longer SGML and instead a simplified version of it.
  • didntreadarticl 4y ago
    Its true, I can bang together an XML doc by hand with less worry than if I type out some JSON
• riggsdk 4y ago
  My web-technology professor at my uni (around 2007) was a big fan of XML and all the surrounding technologies. He saw it as this beautiful interconnected system where the web being pure XML would allow all data in the world to be queried like a database and transformed into any format you wanted. The web sure didn't go that way...
  • didntreadarticl 4y ago
    Thats "XML - the religion"
  • kzrdude 4y ago
    Basically, he was in love with serialization and connecting services together, that part is cool. It's just a lot more diverse in serialization now than before. And a lot of these projects compete in reducing overhead - they are orders of magnitude more efficient than XML.
  • timeon 4y ago
    I think it was called semantic web or Web 3.0.
    • oaiey 4y ago
      And then history repeats and we call this now blockchain and the mess around it ;)
• daitangio 4y ago
  In my huble experience: - XML parsers were quite bad in the old days (2000), even in java land. - Parser speed is a functin of the input size. And XML inputs are quite big, too big in my humble opinion. - you have tag attribute and tag value, and so people get confused on how to use them for simple scenario. - & must be escaped but no one does it. So when 'AT&T' ended up in a stream created by "hand" by a COBOL procedure, the XML got suddenly broken - < and > musty be escaped, and so your SQL queries must be escaped JSON is simply an associative hierarchical maps. A Lot of 1995 PHP code used the same data structure and just works. No attribute, only hierachy recursive structure. Recusion always wins.
  • adrianmsmith 4y ago
    That's all true, I'd just add that in JSON you have to escape " in strings just like you have to escape & < and > in XML, so there is still the potential for e.g. COBOL software to produce invalid files.
    • GoblinSlayer 4y ago
      JSON: "path\to\file" XML: <a>path\to\file</a>
  • bambax 4y ago
    > Parser speed is a functin of the input size. And XML inputs are quite big, too big You don't have to parse the complete document to do something about it. You can use a streaming parser, and you can execute XSLT on the fly.
    • zaphar 4y ago
      This is true but in the early days XML framework libraries gained a well deserved reputation for poor performance because they would parse into a DOM first and then serialize from there. I improved the runtimes of several projects from hours to seconds by switching the serialization from DOM to SAX. The prevalence and focus on the document model for every usage of XML resulted in a reputation hit. One that XML has really struggled to overcome.
• cmrdporcupine 4y ago
  In many respects the failure of XML to live up to the grandiose promises made in the 90s was due to the lack of decent tools around XML. Decent structure-aware, refactoring, editors didn't exist then, and barely do now. XML cries out for something like paredit, but dumbed down and tag aware. The author shouldn't even have to see the textual representation of the tags. But, primarily, the thing that made JSON win out is that it reflects the existing semantic/data-structure model of an actual programming language (and approximates that of many others.) XML (and XSchema, oh god), has this mixture of associative and sequentially ordered data, and two separate kinds of associative/nesting models (elements vs attributes). It wants to eat the world with its new semantic model, but it doesn't offer any particular semantic advantages and doesn't match what programming languages (or relational databases for that matter) work with. And then on top of that the syntax is just ugly to read. Still there was a moment in the 90s where I found XML kind of exciting and interesting. I don't really recall why now? Seemed everybody did.
  • rprospero 4y ago
    I also remember being excited about XML in the 90s and I can recall why. At the time, every application I used had its own bespoke file format and needed a custom parser to read its output. This especially applied to several applications storing hierarchical information in CSV files with their own way of delimiting CSV data as content in a CSV cell. The switch to XML meant that I'd have to figure out the tag soup that the developer had chosen for their XML data, but that was so much more comfortable than figuring out the goulash of ASCII escape tags in the old format. XML is like the pager. It might seem clunky today, but it's better than having to tell the baby-sitter the phone number for the restaurant and theatre you'd be visiting that night.
    • syntheweave 4y ago
      The interesting thing for me is that I've circled back to "CSV is good, actually" since for loosely structured source input, it has few equals - it lets you organize by cell, and you can use spreadsheet software to edit it. The balance shifts towards schema generation once you want to apply a specific model on the data, but "import CSV to my schema" is convenient as an interface to that. XML also has a place as an interface, but it's much more niche, since most interfaces that are hierarchical-document-shaped are going to parse text instead of bracketed entities. I think we got a bit excited about how well HTML worked at the time.
• raverbashing 4y ago
  XML seems like the apex of "design by committee" (and I mean, didn't we have some thick books about it? What for?) Nobody cares about 99% of that
  • pulse7 4y ago
    I am happy we are not using SGML, which is a base for XML and is MUCH MORE complex and is also a standard...
  • bazoom42 4y ago
    XML itself is a pretty focused spec. XML schemas and the whole SOAP stack is where it went off the rails.
    • oaiey 4y ago
      XML was flawed due to XHTML. The key spec was XML Infoset. It removed many capabilities what XML had and focused on data transfer not document representation. That is basically JSON but more powerful (comments + namespaces + attributes). Personally, I think you cannot operate a interface without a schema. There is always a contract. Within your own team you may not care but as soon as two team work with different order on things, contracts are needed. And yes, SOAP, WS-*, XSLT, etc. is where the madness starts. But to be also honest, they used XML, they are not XML.
      • HelloNurse 4y ago
        I've always had a soft spot for idref attributes, intended to support internal linking and graph structures in documents and never seriously adopted; I suspect that more important XML mechanisms exhausted the annoyance/complexity budget of implementations, until the tree-structured data applications crushed document applications as you describe.
        • oaiey 4y ago
          Graphs are always hard. I would love seeing graph databases to be more common, but no.
• Devasta 4y ago
  XSLT is great, the problem is that the browsers stopped at XSLT 1. XSLT 3 is a different beast, and XSLT 4 is being worked on at the moment.
  • bawolff 4y ago
    I think the true lesson of xslt, is xml makes a terrible syntax for a programming language. The language itself minus the syntax is fine, although i think many people prefer a more imperative approach.
    • oaiey 4y ago
      XSLT was also a terrible combination of two principles: Imperative coding + data pattern matching. For a novice beginner - and me at the time - I was never clear which pattern to use and how it best fit together.
  • doctor_eval 4y ago
    I wrote many thousands of lines of XSLT back in the day, converting XML into XSL:FO and pumping it through FOP. It worked remarkably well. It was my second experience with a declarative language (SQL being the first). There were some great resources - libraries of code fragments, similar in spirit to tailwind ui - and people did crazy things with them. We eventually abandoned it, after many years. It was indeed terribly difficult to work out how a document got transformed, and when returning to a transform after a long time working in other languages, you could easily spend a day just trying to work out how some trivial thing worked. I remember it fondly, but I wouldn’t do it again.
    • tragomaskhalos 4y ago
      What XSLT really needed was a gui where you could play with the template and the input and see the output change in real time, a little like how those regex websites work. With a few colours and arrows to elucidate what bit was doing what. Not a trivial undertaking, granted. I wonder if such a thing was ever produced?
• _glass 4y ago
  Sometimes I just don't really see it as a competition. For my research work often XML is a markup, which JSON is not. If I want to qualitative code a text, this is perfectly doable by hand: <note> <paragraph>This is a <code vibe="positive">remarkable</code> text. </paragraph> </note> If you do it in JSON, it is not really readable anymore, and I would have to write GUI for the input, e.g., { "note": { "paragraph": [ "This is a ", { "code": [ { "vibe": "positive" }, "remarkable" ] }, "text." ] } }
  • nordsieck 4y ago
    IMO, you made the JSON unreadable with all the extra whitespace that you didn't add to the XML. {"note": {"paragraph": ["This is a ", {"code": [{"vibe":"positive"}, "remarkable"]}, "text."] } } Also, in this particular case I think the child/property dichotomy works in the favor of XML, but typically I find it to be more of a liability than an asset.
    • quectophoton 4y ago
      If you use arrays instead of objects, it becomes JsonML[1]: ["note", ["paragraph", "This is a ", ["code", {"vibe": "positive"}, "remarkable"], " text."]] [1]: https://en.wikipedia.org/wiki/JsonML https://en.wikipedia.org/wiki/JsonML This is also why I find Mithril.js so pleasant to use without JSX, because it's basically JsonML.
      • sph 4y ago
        Use parens and you have S-expressions. No need for all that noise. (note (paragraph "This is a " (code (:vibe . "positive") "remarkable") " text.")) Lisp was invented in 1958 and we routinely rediscover it, and reimplement it badly.
        • quectophoton 4y ago
          Yeah, S-expressions are way more pleasant to write. With the benefit of a lot of hindsight, S-expressions seem like a superior choice for writing web applications (instead of HTML + JavaScript + some JS framework that writes HTML again (regardless of DOM vs Virtual DOM)). Even though I prefer dialects like Fennel for programming rather than Common Lisp (I'd probably be fine with Clojure and Janet as well, but I haven't tried them), I wouldn't mind any dialect if that means I could use S-expressions instead of HTML+JS, assuming the amount of effort put into sandboxing that approach were as much as the effort that has been put into the current approach.
• bambax 4y ago
  > XSLT anyone? I used to love XSLT (I would probably still love it if I still used it, but the projects have mostly disappeared). Pattern matching is akin to event driven programming: just deal with what you have, if and when you have it. It was very clean and never broke.
• throw0101c 4y ago
  > XML vs JSON Fun fact: Tim Bray was the/an editor on both specs: * https://www.rfc-editor.org/rfc/rfc8259 https://www.rfc-editor.org/rfc/rfc8259 * https://www.w3.org/TR/xml/ https://www.w3.org/TR/xml/ I wonder if he'll commemorate/note the anniversary in some way: * https://www.tbray.org/ongoing/ https://www.tbray.org/ongoing/