25 ms·

In Defense of XML

• bloak 6y ago
  The article compares XML with JSON and YAML. That makes sense for some applications, but for other applications, like a structured text, I'd compare it with Markdown. I'm not happy with XML or Markdown for my source, where "source" means what I edit or what I put under version control, which aren't necessarily the same thing. I find it better to invent my own adhoc notation and write a Perl script to verify it and convert it into XML, HTML, Markdown, JSON, ... It's a shame, but the sad fact is that humanity does not yet have an adequate and widely used way of representing structured text in a computer. XML is perhaps the closest I've seen, but the tools don't seem to be good enough or sufficiently available, and now XML is also unfashionable so I don't suppose the situation is going to get any better.
  • tannhaeuser 6y ago
    SGML, of which XML is a proper subset, has had custom Wiki syntax parsing (such as for a fragment of markdown or CSV) since 1986. Agree with what you said about pointless comparisons of JSON vs YAML vs XML, though. Edit (regarding your point about humanity not having an adequate and widely used text format): we have SGML and it's offsprings XML and HTML. We won't be getting any new formats/standards in these times of platform economy and vertical integration, ever
  • ChrisMarshallNY 6y ago
    You ever hear of BNF[0]? Ugh. I used to write BNF parsers for a proprietary email system in the early 1980s. I’d rather bang rusty nails through my kneecaps. It was a fairly complete notation, though. [0] https://en.m.wikipedia.org/wiki/Backus–Naur_form https://en.m.wikipedia.org/wiki/Backus–Naur_form
  • Finnucane 6y ago
    > I'd compare it with Markdown Which is a pretty terrible comparison. Markdown allows you to add some structural annotation to your text as you write it, without having to type a lot. That's a useful thing. But textual markup systems like TEI and Docbook go way beyond what you can do with Markdown (also, what can be practically managed in a less 'verbose' system like JSON). They also aren't really intended as authoring tools in quite the same way; you don't code them as you work. well, you might do some hand-editing of your TEI in some specialized academic archival work, but you wouldn't use that kind of coding for writing a new text.
  • earthboundkid 6y ago
    Does anyone know enough about LaTeX/TeX or RTF to compare them to XML here?
    • wbl 6y ago
      LaTeX is something very, very different. It's based around macro expansion and oriented toward print, not programmatic transformation. For example if I want a programmatic table of contents for an XML document it's a simple transformation or DOM extraction exercise. If I then transform to XML-FO that will fill in the numbers. LaTeX does multiple full document renders to obtain auxiliary data for a later render to use. No XML based system does what LaTeX can do for text rendering. It's not impossible they just haven't bothered. What's more impossible is to match the ease of writing text. LaTeX gets in the way much less for most text.
  • sergeykish 6y ago
    It is not lost. "application/xhtml+xml" accepted by all browsers. Browser DOM is XHTML in disguise document.contentType //"text/html" document.body.namespaceURI //"http://www.w3.org/1999/xhtml" HTML is just a serialization optimized for human authoring, it has its faults script = document.createElement('script') script.textContent = '</script>' script.outerHTML //"<script></script></script>" It may be humanity does not have an adequate and widely used way of plain text authoring of structured text. DOM diff and patch may be lacking as well.
  • fanf2 6y ago
    I'm amused because markdown started off with John Gruber inventing his own adhoc notation and writing a Perl script to convert it into HTML ...
• nimish 6y ago
  The major issue with XML is all the garbage built on top of it like SOAP, WS-* and horrors like XMLDSIG. Used purely as a markup language it's ok but you really don't want to be mucking around with stuff like canonicalization at all if you value your time.
  • kanox 6y ago
    > Used purely as a markup language it's ok But people don't use xml as a markup language; they use it for data interchange and for that purpose it's horrible because it maps very poorly to data structures in most programming language.
    • paledot 6y ago
      Bingo. This is why I hate XML. Nothing wrong with the syntax - I hate that I have to massage arrays, dicts, etc. in cryptic ways to generate the XML output, then massage them right back at the other end. And PHP's SimpleXML module, at least, is anything but - lots of iterators, casting objects to string, and "where did my data go?".
    • guiraldelli 6y ago
      > [...] and for that purpose it's horrible because it maps very poorly to data structures in most programming language. I disagree with you. A XML file is, by definition, a [context-free grammar](https://en.wikipedia.org/wiki/Context-free_grammar https://en.wikipedia.org/wiki/Context-free_grammar), the same type of grammars used to specify programming languages. I will make it clearer with the examples below: /* a simple data structure */ struct Point { int x; int y; }; <point> <int name="x"></int> <int name="y"></int> </point> /* a recursive data structure */ struct Person { std::string name; std::vector<Person> children; }; <person> <string name="name"></string> <vector type="person"> <person> <string name="name"></string> <vector type="person"> </vector> </person> <person> <string name="name"></string> <vector type="person"> </vector> </person> </vector> </person> To me, it is immediate to see the correct data structure in both examples. If I had to write the second one in JSON, for instance, I would lose the "template type-information" of the list (vector).
• nerpderp82 6y ago
  No need to defend XML. XML stands the test of time. Yaml has become the evil it was meant to replace. If XML had-had a command line structured editor at the beginning and integrated with JS a little bit better, it wouldn't have ever fall from grace. It pains me that json doesn't have comments, and that so much energy has been expended basically getting JSON to the tooling and conformance support that XML already had.
  • Aloha 6y ago
    I like XML, I hand write a ton of XML at work, I like it because I consider it to have some built in sanity checking, its something that is obvious even when using an text editor if its correct or not.
    • arethuza 6y ago
      Most editors these days will do similar checking of JSON syntax and a lot do checking against JSON Schema as well if you have one handy.
  • aspaceman 6y ago
    I also like XML. Getting XML instead of JSON implemented at work is a damn pain in the ass though. I work in GPU research, and the appeal of JSON over XML to a underknowledgable PI is immense. I think it comes from being able to read it pretty easily as a non-technical person.
  • ptx 6y ago
    In what way would you have liked to see the JS integration improved? I was surprised recently to find out that the browser API doesn't provide a streaming parser for XML, but it doesn't do that for JSON either, so that one at least is a draw.
    • Marazan 6y ago
      E4X
• nsonha 6y ago
  who even cares, just use things that everyone uses. XML can be used in a schemaless manner and json/yml can be used with a schema. Eventually the more compact formats are more popular because people can use them for other things such as object dump and actually read it. And a very big config file can be handwritten and code review without too much hassle. It's not about schema or association with enterprise. I do miss SOAP though. Why are we still writing plumbing code in 2020. And no grpc isn't the answer there is still plumbing code, what's the point?
  • coding123 6y ago
    REST was the answer, because why have a schema define a specific input, when instead it's a lot more fun to make the input come from one of these fun places: Path, Query, Body (Even with a GET - because why not?), Header, AAND let's not forget the Method!
    • nsonha 6y ago
      let's not forget the prescribed verbs that give rise to CRUD APIs
    • sk5t 6y ago
      To play devil's advocate: why should we have all these weird little files knocking about in /etc, when we could query and mutate everything of interest on the system instead via a Management Instrumentation API?
      • nsonha 6y ago
        wrong thread?
        • sk5t 6y ago
          Not at all - sort of an oblique argument for the unix way / "worse is better" and reasons why JSON and the disorderly REST-ish array of techniques has come to dominate over SOAP, XML, WSDL, etc. The unix way: text files in /etc, human-readable, each kind of does its own thing, but it works. Compare to: WMI, Windows registry, complex NTFS permissions, a bit more unified but ultimately a drag to deal with; complex app servers like Websphere; CORBA; and all the WS-* stuff.
• Tainnor 6y ago
  I'm a bit annoyed that the author of the article seems to be imply that the move away from XML is just due to hype. Also the point about the ad-hoc client validation doesn't seem right to me. If the server changes the XML response, the client may be able to fetch the updated schema (assuming the devs didn't forget to publish the update...), but then what? You still have to handle the new or updated fields in code somehow. My biggest gripes with XML are twofold: - It's as annoyingly verbose as Java is; I just get lost looking at all the tags (the namespaces don't help). - The community seems to have this obsession with solving every problem under the sun with more XML and more specifications. I believe, this is wrong. Trying to standardise across the whole range of data interchange and configuration needs is the wrong approach, IMHO. JSON wins here, because it gets out of the way. I do wish JSON had comments and that JSON schema was better (for when you really need it), but nobody ever had an expectation that keys are unique across all JSON documents in existence, something that XML somehow insists is necessary for its elements and attributes. But what the author is right about is that YAML is an absolute nightmare, and I can't understand why it continues to be so popular. Apart from the dozens of ways of writing booleans or strings, it's also way, way too easy to forget what level of indentation you're currently at, especially if you're navigating large files like Kubernetes or CI configs. I think more projects (at least larger ones) should adopt their own DSL for configuration. For example, I find the terraform config format much cleaner than any of the YAML stuff.
  • kanox 6y ago
    The biggest advantage of JSON and YAML is that it has a very straight-forward object model consisting of literals, lists and dicts. All of these constructs map very easily to native data structures in most languages: you can just "load" and "save" an arbitrary json or yaml document. The XML DOM is very different and does not map in an obvious way to objects in any programming language: you either use a DomDocument or object serialization for a subset of XML. This alien object model makes programming with XML painful and verbose for no gain. Sure: standards for xml schema and xpath are pretty nice but there are json equivalents which don't have to deal with elements and attributes. If standardization around YAML and XML was equally good would anyone pick XML? > way too easy to forget what level of indentation you're currently at This is easily solvable by tools. How is it worse than getting lost in braces or open/close tags? > I think more projects (at least larger ones) should adopt their own DSL for configuration. Please don't. JSON, YAML and XML config files can be easily and safely manipulated in all programming languages, for custom DSLs people end up using brittle regexps. It's not much better than putting config consts in a code file.
• Multicomp 6y ago
  I really would prefer to use XML for my next project, but self-censored myself so that if this project is ever open source and has other contributors, I'm not instantly dealing with hordes of users who want to convert it to json for data transfer objects. Maybe it is because my baby duck syndrome came with xml web services and asp.net web forms, but it is amazing how much scaffolding and engineering work we threw away and are now reinventing. (Wsdl, schemas, etc)
  • dnautics 6y ago
    Maybe I don't understand something about xml. As in, best practices. When designing an xml schema, When are you supposed to use innertext, when are you supposed to use a tag inside your tag, and when are you supposed to use a tag property?
    • xapata 6y ago
      First, consider whether someone will ever want to convert to JSON. If so, make that easy.
      • dnautics 6y ago
        it's sad that this is downvoted, since it's also true. For example, AWS emits its response as XML, and it's a chore for boto to convert that to a json response. If you don't want to use boto (say you're not in python) and you prefer getting the response in json, you might be out of luck.
    • ZeroClickOk 6y ago
      Mag property is mostly for metadata, but it does not stop it to use it for this purpose. All three options are valid and you can use as will, xml is flexible enough in this point (unless your xml consumer has some restriction, then follow the consumer spec)
    • roel_v 6y ago
      Quite often it just doesn't matter that much. It's a matter of 'taste', as are so many things that are 'designed'. And yes you'll make mistakes a few times. The correct response to those mistakes is to take them as learning opportunities and not dwell on them, instead of blaming and trying to replace the tools. Of course one can use this exact argument to stave off any change ever...
• Kednicma 6y ago
  The main problem with XML is that writing a safe XML parser is difficult. But writing, say, a safe JSON parser is not much easier; writing a safe ASN.1 parser is much harder. So it's not clear whether there's a better possible declarative format.
  • aidenn0 6y ago
    Writing a safe tagged netstring parser is pretty darn easy, for many definitions of safe. There's always the issue of very deeply nested data structures causing lots of allocations, but no nested parser can avoid that. Full featured XML parsers can read arbitrary files from disk, which is usually not what you want from a data interchange format.
  • AnimalMuppet 6y ago
    Gah. I dislike XML, but I had forgotten how much I loathe ASN.1.
  • earthboundkid 6y ago
    XML is hard to parse because they mixed compression concerns in with encoding, which is a security nightmare. What’s hard about JSON? There was some looseness around the spec for certain characters, but overall, it’s pretty straightforward.
• tantalor 6y ago
  > JSON is JavaScript native, while XML is not Yet we have XMLHttpRequest to thank for the last 20 years of the web.
  • jaywalk 6y ago
    It is pretty ironic, although XHR does predate JSON.
    • tantalor 6y ago
      Crockford says JSON existed since JS was formalized. He says he discovered it in 1999 but it was in use Netscape as early as 1996.
• emmanueloga_ 6y ago
  XML specified with a mix of RelaxNG and Schematron is a really nice pairing. Both are interesting and a little different to the usual schema languages. RelaxNG is like "regular expressions for trees". It has a compact syntax like this: start = element library { element book { attribute title { text }, element page { text }+ } } .. so books in this library (root element) should have a title attribute and one or more pages. There's a (pretty geeky [] :-p) description of the algorithm here [1] (: Brzozowski derivatives + Haskell!). Schematron is another schema language that allows specifying constraints as a series of pattern rules: <schema xmlns="http://purl.oclc.org/dsdl/schematron"> <pattern> <rule context="book"> <assert test="let $b := .[starts-with(@title, 'A')] return $b/page/count() >= 100"> Books whose title starts with "A" must have 100 or more pages. </assert> </rule> </pattern> </schema> So it allows specifying constraints that would be too tedious or impossible with RelaxNG, and allows keeping the RelaxNG grammar simple. The test on the Schematron "assert" element in the example uses "let expressions" [2], one of many additions that makes XPath and XSLT 3.0 feel a lot like any other modern functional programming language (other features: higher order functions, maps/arrays/JSON support, and more). This presentation [3] shows a few more 3.0 features. If lisp is for lists, then XSLT definitely is for trees! I suspect as people start forgetting the baggage of SOAP and XSLT 1.0, the language is going to become more and more popular since it is so useful. BTW, there's now a JavaScript implementation that runs on node and the browser too [4]. 1: https://relaxng.org/jclark/derivative.html https://relaxng.org/jclark/derivative.html 2: https://www.w3.org/TR/xpath-30/#id-let-expressions https://www.w3.org/TR/xpath-30/#id-let-expressions 3: https://www.kosek.cz/xml/2019xmlss/Kosek_XSLT4DailyCoding.pdf https://www.kosek.cz/xml/2019xmlss/Kosek_XSLT4DailyCoding.pd... 4: https://www.npmjs.com/package/saxon-js https://www.npmjs.com/package/saxon-js
• tialaramex 6y ago
  One reason to dislike XML is that it can't actually encode text. This is deliberate, key people involved in XML standardization really hate some of the characters (particularly some "control characters") in text, they don't think those characters should exist, so, they outlawed them in XML. I know what you're thinking, "Just escape them". Nope. I didn't say you have to escape them, I said they're outlawed, the XML definition says these characters, whether escaped or otherwise, must not appear in an XML document and some XML libraries enforce this requirement from the standard. Now of course if you know this will happen and you want to sidestep it you can encode all your text in some other way (e.g. as Base64) and then use XML, but wait a minute, the whole point of XML is that it's a text encoding, for encoding text, so this is crazy. In systems I've built that are mandated to emit XML and yet are expected to handle text anyway, I patiently explain the problem and unless people seem stirred awake and back off on requiring XML, I then convert all prohibited characters to U+FFFD - the Unicode replacement character - and they can keep both halves of the resulting broken garbage.
  • saurik 6y ago
    A "control character" (such as form feed) is kind of by definition not "text", but more importantly this was fixed for XML 1.1, which is like 14 years old at this point.
    • matharmin 6y ago
      I have never seen XML 1.1 used in practice. How many parsers actually support it?
      • GoblinSlayer 6y ago
        Interoperability is exactly the reason why control characters weren't added to xml 1.0. And >You are encouraged to create or generate XML 1.0 documents if you do not need the new features in XML 1.1; XML Parsers are expected to understand both XML 1.0 and XML 1.1.
      • ebruchez 6y ago
        XML 1.1 was considered a failure by W3C and it is not recommended that anybody use it.
• butterisgood 6y ago
  In the early 2000s XML was like violence - if you didn’t get what you wanted out of it you just used more.... or some horrible analogy like that.
  • TOMDM 6y ago
    I feel like a horrible analogy is itself the perfect analogy for XML.
• dragonsh 6y ago
  Reason XML went out of favor I think has to do with decision to focus more on efficient parsing by machine and less on readability and simplicity. There was a competition between XSD (XML Schema Definition) [0] and RelxNG [1] for defining the structure of XML. Personally I preferred RelaxNG, but at that time Microsoft and many big players converged on XSD. So XSD won but XML is out of fashion. I wrote a XML encoder and decoder with XSD for an EDI application handling 2-3GB files in C++ using MSXML and it was very slow, improved the speed using stream parser, but still slow. Later on using libxml rewrote the parser in C with RelaxNG and the processing time reduced from hours to seconds on the same hardware. At that time as RelaxNG lost in spite of having elegant structure compared to XSD. I had a lot of arguments with my friend that RelaxNG will win because it's readable, simple and support every use case supported by XSD. But due to support from many vendors especially Microsoft (as most enterprises were using microsoft) an inferior solution like XSD won, because Microsoft focused more on computer consumption of format instead of human. So although XSD can be read no one could understand it. This is one of the reason JSON, YAML and TOML have picked up because they offer the readability and parsing at the same time. Hopefully people can understand it this time and do not destroy JSON with complex JSON Schema definitions. Take a look at both: Relax NG example in compact syntax: element book { element page { text }+ } Relax NG exmaple in non compact syntax: <element name="book" xmlns="http://relaxng.org/ns/structure/1.0"> <oneOrMore> <element name="page"> <text/> </element> </oneOrMore> </element> ------------- XSD example: <xs:element name="book"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="page" type="xs:string" maxOccurs="unbounded"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> [0] https://www.w3.org/TR/2008/REC-xml-20081126/ https://www.w3.org/TR/2008/REC-xml-20081126/ [1] https://relaxng.org/ https://relaxng.org/
  • hnick 6y ago
    There's also the question of using a SAX or DOM based parser. More than once, I've had to update a program using 32-bit perl from DOM (simple, fast) to SAX (slower but more control) as documents grew and the scripts crashed due to Out of Memory errors. Using SAX gave us event based handling to ignore certain nodes, or cache them to disk in another format as they got too big, and other fun stuff. Rule of thumb was to multiply the document file size by 10 to get the memory footprint with a DOM approach, because of all the objects, relationships, and metadata that has to be stored for everything. One individual records got up above 100MB on disk we were in the danger zone. Whereas JSON just loads into hashes and arrays and tends to not pose similar problems.
• dec0dedab0de 6y ago
  My biggest problem with XML was using APIs written in Java where it seemed like all the internal classes were just dumped however they came out. I think the simplicity of JSON forced people to think about how to serialize their data. This Simple serialization made things easy for multiple languages, and therefore it became popular.
• acdha 6y ago
  I don't disagree with every point the author makes — and I cry inside a bit every time I see YAML used for serious work, with data loss and outages caused by that ambiguous — but I think it'd be useful to focus on why XML became unpopular. Java and SOAP culture had a role there but most of it came down to two things: 1. The user experience sucked 2. The developer experience sucked What XML needed was good quality editors, validators, programing language libraries, and, above all, documentation for people who aren't on the standards committees. What we got instead were people on standards committees and enterprise architecture groups trying to show off what deep thinkers they were, with the assumed inevitability meaning that boring details like actually implementing something could be left as an exercise for the student. Namespaces are a great example: this is a core language feature, a really powerful tool, and you'll hit the laziest possible implementations as soon as you try to use them. You start with something reasonable: <foo xmlns="http://example.org" xmlns:custom="http://example.org/somethingelse"> <bar> <custom:baaz>…</custom:baaz> </bar> </foo> That's a nice way of separating ownership, looks great. Then you start trying to parse it, write XSLT or XPath, etc. and find that you can almost never write “custom:baaz" the way it shows up in the document, or often even /foo/bar, because the tools expect you to work with the internal representation (“{http://example.org}foo/{http://example.org}bar/{http://example.org/somethingelse}baaz” http://example.org}foo/{http://example.org}bar/{http://examp...) and so you might see error messages saying "<custom:baaz> not found” in a document which has that exact string, validation errors from tools which use different libraries than what was used to author the document, or, better, silent data loss because you didn't notice that some selectors weren't matching. Many programming language interfaces will require you to repeat those declarations everywhere because, of course, it would have been far too much to expect that a query against element <bar> inherit the namespace declaration from its parent. Again, this is a key feature which has been around since 1999 and decades later you can still still find people writing things like //*[name()='baaz'] or stripping namespaces entirely before rage-quitting XML. Everything harder is worse: basic usage requires internalizing 6 different ponderous specs on different release cycles, figuring out which of the examples had never been tested and which worked when the author wrote them but are now unsupported by the particular tools you're dealing with, etc. Bonus points for realizing that you had a never-valid document which was just punted down the line by multiple enterprise systems which have had increasingly lenient validation added over the years by developers who were told it was too expensive to fix the previous system. I'm not sure XML can be saved at this point but I'd start by modernizing libxml2 since half the open source world is stuck in stasis when that stopped getting new features in the early 2000s, and then focusing on non-expert usage. A full GUI editor would be a lot of work but simply having high-quality command-line tools and implementations for common programming languages would go a long way towards not giving people excuses to switch.
• jandrewrogers 6y ago
  My reasoned objection to XML, having used it for many years, is that it is unconscionably expensive to parse. At scale, XML is extremely computationally expensive in almost every dimension. It is not a good way to represent almost any non-trivial data structure, but that is frequently its sole use case. XML is a great way to expand your carbon footprint in the data center. Today, there are very, very few cases where I would recommend XML despite it being widely specified for standards.
  • zaphar 6y ago
    While I don't usually reach for XML when I need a data transport format this particular criticism is somewhat unwarranted. SAX parsing of XML is pretty cheap computationally. The problem is cultural more so than technical. Pretty much every language ships with a DOM parser. Not all of them ship with a SAX parser. As a result DOM is the more predictably available choice. DOM Parsing is both computationally and memory expensive though which I think is where XML gets this reputation from.
    • rjkennedy98 6y ago
      > SAX parsing of XML is pretty cheap computationally. SAX parsing is also very complex programatically. Who wants to switch on various SAX events when handling a XML document? No, we want the full thing parsed into an object. I've spent a decent amount of time in the XML world and I've only seen people use SAX when performance was a large concern or when parsing enormous XML documents.
• Tainnor 6y ago
  Just as an anecdote, I recently had to generate some XLSX which, even for XML standards, is a horrible standard and the only library that seems to be able to accomplish this (for Java) consists basically of some autogenerated classes from the XML schema itself that have zero documentation. But the worst part was when I tried to add an integration test for it. I tried comparing the generated file with a fixture file, but that didn't work, because XLSX are zipped XML files and zip isn't deterministic. But even comparing the two file directories of the unzipped files and then comparing XML files pairwise didn't really work, because apparently, XML can be serialized in different ways and it turned out that my CI somehow serialized it differently than my machine (somehow the namespaces were handled differently - not sure if it was an OS issue or some transitive dependency issue). In the end I was only able to solve it by using another library that can specifically diff XML files.
  • virtue3 6y ago
    if you smash the file permissions and dates on the file it can be deterministic.
    • Tainnor 6y ago
      Maybe (didn't look into that), but that wouldn't have solved the "somehow, XML is serialized differently in some cases because of namespaces" issue which, honestly, I didn't even try to understand because it seemed like a pointless rabbit-hole.
      • sk5t 6y ago
        Indeed there's generally no guarantee that two XML serializers will choose the same namespace aliases, or handle ignorable whitespace the same, etc. You gotta think of XML as an object graph (and not a bunch of tags and text nodes) to have any joy at all with it. Unit tests should not compare the serialized bytes, but rather deserialize and/or event-parse and compare the graphs or events. I'm not suggesting any of this is pleasant, but, there it is.
        • 6y ago
• deckeraa 6y ago
  One thing not mentioned in the article is the lossy nature of XML when coming from data structures with concepts of arrays and maps. A typical array in XML looks something like: <foo> <bar>First element</bar> <bar>Second element</bar> </foo> which can lead to issues if the second element isn't in there: should bar just be a property of foo or should it be an array? (I'm definitely open to correction on this if someone knows a better way; my experience with this particular issue is from writing a parser to take XML and turn it into a MUMPS-native data structure. I mostly had to have the parser take an educated guess and then let API users specify which elements were arrays if they wanted it to parse the same way against all inputs). This is analogous to how saving Clojure sets (e.g. #{:a :b :c}) to a JSON document in CouchDB is also a lossy operation because JSON doesn't have sets, just maps and arrays.
  • cmwelsh 6y ago
    Seems like you’re more interested in encoding your implementation details into a text document. This seems like something that could be left to the parser. Provide the target types for the deserialization. This isn’t Python pickle or Java serialization - it’s a text string.
    • deckeraa 6y ago
      Fair enough. Though wouldn't that work better with languages like Java where the programmer typically ends up making a type or class for most things? With languages like Clojure it's fairly typical to declare no classes or types and to simply have your data structure be a composition of maps, sets, and vectors, etc. I suppose you could use your Clojure.spec keywords as the tag names in XML, but that's probably going to be more work than (clojure.edn/read-string (slurp "my-data.edn")). Could be an interesting option if you had to use XML as an interchange format.
    • rcxdude 6y ago
      Problem is XML is extremely frequently used to represent such types (probably even more so than it's used to represent marked up text). And it's not very good at it.
  • 6y ago
• lmm 6y ago
  > IMHO, this argument is shallow, as all 3 formats are text-based. Thus, you can - and should - compress files. Parsing might be a bit slower, but it depends a lot on the exact parser (and the associated technology stack). In the end, the overhead of transmitting and parsing in XML - if any - is negligible compared to the total time in the whole use-case. That doesn't help a human reader. The XML overhead doesn't matter to computers, agreed, but it matters a lot to people. > Composable > While XML doesn’t strictly enforces namespaces, it’s considered a good practice. This way, similarly-named entities defined in different namespaces can co-exist in the same document without confusion about semantics. Sounds useful but it actually isn't. JSON is composable just fine: just put a JSON document as a value in another JSON document (something you can't actually do in XML, you have to strip the headers). By contrast, XML namespaces are this hugely complicated non-solution to a problem that no-one ever actually has: if you write an XPath expression then it might select something inside an embedded XML document instead of the thing you were actually looking for, because the embedded document might use the same tag name. So to protect you from this bug that has never happened, you can't actually write an XPath using the tag names you see in the document, you have to either expand out all the namespaces to their URLs (and good luck with what your XPaths look like now), or somehow "register" all your namespaces with your parser before you parse. It's just stupid overengineered nonsense. > Several XML grammar implementations are available: Document Type Definition, XML Schema, Relax NG, etc. The most widespread one is XML Schema. Since a XML Schema is also written in XML format, a web server can host it. Then you can reference it by a publicly-accessible URL. > This approach solves the above issues: when a client receives an XML document, the former looks at the XML Schema URL. It can then fetch it, and check that the data conforms to the schema. > Changing the data format is as simple as versioning the XML Schema file, and publishing it under a new URL. And then when your webserver goes down, everyone's programs stop working because they can't load your schema. Has XML schema ever actually done anything useful for anyone?
  • sergeykish 6y ago
    Once I've joined a project and there was a problem with text selection in embedded PDF.js It took some time to find out that CSS rules clashed with PDF.js invisible markup that provides text for selection on top of <canvas> rendered document. And I am not the only one [1]. Solution? Embed namespace in class name [2] like it is C - gtk_window_new, glBegin, XOpenDisplay. Yes, namespaces in XPath looks awful, entire plain text XML authoring is awful. XML is application format (hint application/xml), maybe it should not be touched without XML editor. [1] https://www.google.com/search?q=css+name+collision https://www.google.com/search?q=css+name+collision [2] http://getbem.com/introduction/ http://getbem.com/introduction/
• austincheney 6y ago
  There are a couple of things this article gets seriously wrong. * Front-end. XML is perhaps more compatible to that front end than JSON because an XML document can make use of CSS and JavaScript where JSON cannot. See this example of a language I created in another life and please that document is literally the XSD schema file: http://mailmarkup.org/mail-documentation.xsd http://mailmarkup.org/mail-documentation.xsd Also, if you want to use either format in the front end you have exactly the same one step: parsing whether it’s using JSON.parse or DOMParser(). Actually, the browser preferences XML here too because the browser can be told to parse the XMLHttpResponse response and thereby return DOM document object. https://developer.mozilla.org/en-US/docs/Web/API/DOMParser https://developer.mozilla.org/en-US/docs/Web/API/DOMParser * Failed for two reasons and enterprise is not one of them. XML has some super intelligent features and technologies. The more intelligently you use it the more powerful it becomes. Most people were not using it intelligently. Most people were using it in the most primitive way possible without any advanced features. In that case it was just a bulky text wrapper. Most of the Java configurations were dumb like that. XML is big. The charm of JSON is that the syntax is tiny. When pushing data over the internet tiny is better. The only way to make up for the syntax bloat was to do more intelligent and powerful things which XML wanted to do but most users refused to figure out.
• fulafel 6y ago
  Interesting that nobody pointed out the tooling dimension of XML's demise yet. (edit: actually there was another comment too: https://news.ycombinator.com/item?id=24623696 https://news.ycombinator.com/item?id=24623696) You really need a high level of support in editors and other tools to make it good for humans to work with, to just showing the AST and to hide the unusably verbose surface syntax. This support didn't materialize widely enough for whatever reason. Of course you can say that it's just a convoluted way of saying the syntax wasn't good enough - but at the time the argument was that tooling will be good enougg and will solve the issue. So it's still a good lesson about tooling.
• wodenokoto 6y ago
  > YAML is to config syntaxes what Python is to programming languages. Seriously, significant whitespaces? That's his critique of YAML? That it is too pythonic? You're not getting far in convincing people of something being bad, if your top argument is "It is like python".
  • franga2000 6y ago
    It sounds like they dislike the fact that indentation matters. I see a lot of people who get mad about that in Python and YAML has the added annoyance of not allowing tabs. Personally, I love both Python and YAML for this exact reason (among others). Explaining a hierarchical system using indentation to an average person isn't too difficult, but even very smart non-tech people will get confused by explicitly opened and closed blocks (if-endif or { }). Without proper indentation, the code is unreadable anyway, so why not actually take advantage of that and get rid of the bracket soup that means nothing to you anyways.
    • tasogare 6y ago
      It’s not the concept of indentation that’s the problem, it’s the implementation. Tabs vs space, smart editors, auto-linters all make it easier or more difficult depending on the situation, which created insecurities by constantly breaking expectations. In case of code, the fact there is not visible difference (most of the time) between tabs and space make it quite easy for bugs to creep in.
      • unionpivo 6y ago
        that's why it's spaces only. If you mix you are asking for trouble, and if you allow to be configured, half will pick one the other will pick other. So the only sane choice is to just pick one and enforce it. And by now most of the editors have python rules baled in, so it's not big problem in practice. By python standard one level is exactly 4 spaces
        • thechao 6y ago
• xaduha 6y ago
  It's too easy to produce some abhorrent XML if you don't put much thought into it, straight from tables and objects. And then people are surprised that what they see is revolting, hard to work with and reason about.
• Cthulhu_ 6y ago
  > IMHO, this argument is shallow, as all 3 formats are text-based. Thus, you can - and should - compress files. Not only that, but converting data to text, compressing, decompressing and back from text to data is kinda dumb; there's technologies like EXI (https://www.w3.org/standards/xml/exi https://www.w3.org/standards/xml/exi) that transport XML data in a compact binary format. It may not be readable in transit, but switching the transport or converting the EXI into text-based XML should be trivial if you want to inspect it manually. But people seem to be reluctant to have mechanical sympathy, even if the data is barely ever read by humans.
  • MaxBarraclough 6y ago
    EXI is 'lossless', right? Trivially convertible back to plain XML? Not much downside then. Ideally the downside that it isn't human-readable shouldn't count for much. Technically that's true of HTTPS too. If it's treated as a communication channel, it shouldn't matter at all. I suppose it depends how good the tooling is. I get the impression it's not natively supported by web browsers.
  • kzrdude 6y ago
    Is EXI usable in a SOAP service?
• maitredusoi 6y ago
  I agree with most comments ! Who can defend XML today? The best nightmare for programmer! Costing billions to ITthe industry (as all major companies use it internnaly and externally). Probably another growth hacking news .... ;(
• zeepzeep 6y ago
  I don't care about anything regarding XML, except the fact that it can read files and make http requests...
• int_19h 6y ago
  XML had its problems, but I wish the baby didn't get thrown out with the bathwater. We got some of the things back (like comments), but e.g. XML namespaces are an amazingly versatile feature when you need to define extensible schemas, or aggregate data from different sources.
• Const-me 6y ago
  I would mention date and time. XML has them standardized, see xs:dateTime, xs:time, xs:date. In JSON everyone is inventing their own incompatible representation, can be various ISO string formats, or various numbers (seconds, milliseconds, etc) from some epoch, look at that mess: https://en.wikipedia.org/wiki/Epoch_(computing)#Notable_epoch_dates_in_computing https://en.wikipedia.org/wiki/Epoch_(computing)#Notable_epoc... C# has XmlReader and XmlWriter classes in the standard library. Technically they are not event based, but conceptually they’re pretty close to SAX, i.e. they implement streaming forward-only parser, and streaming producer.
  • tasogare 6y ago
    C# also has Linq to Xml and the XDocument et al. classes which are a nice way of reading / writing XML. I personally like XML. It’s a bit on the verbose side, but that makes is way more easy to figure out the position in the tree than it is in JSON. It is also more easily extensible thanks to attributes and namespaces. It supports comments which is mandatory for any configuration format for obvious reasons. It has powerfull transformation engine as well as schema capabilities. JSON schema keep producing new draft of its spec, yet the result is not on par with XML, and more painful to write. I’d like for XML to make a come back, not as the behemoth it was once, but for case it makes sense, and configuration files is definitely one of those.
    • Const-me 6y ago
      > Linq to Xml and the XDocument et al. classes Yep, pretty sure the OP meant just them when they placed that green icon in the DOM column and C# row. However, the red cross icon in the table says SAX is missing in C#.
  • roenxi 6y ago
    > ...everyone is inventing their own incompatible representation, can be various ISO string formats... If only we had some sort of international body to standardise these representations. This and the original articles "JSON has no comments [and this is how you do a comment in JSON]" undermine the complaint on a technical basis. String with an ISO standard datetime is perfectly reasonable. And quite standard. Use UTC+0 where possible.
• pjmlp 6y ago
  XML remains my favourite configuration format, anything that came later just ends up reinventing the wheel, and badly with half of the tooling capabilities available for XML processing.
• kavi87 6y ago
  Yeah well just try to use XML as your config format and spit JSON out of it for your frontend, if you are using Java you'll quickly realize how obsolete and inelegant is this horror that they dare call JAXB.
• jorams 6y ago
  > YAML has 22 ways to write booleans - no less! I would argue that XML, in practice, has many more. Everything in XML is a string by default, and only an XSD can provide actual type information. Lots of things don't, and those that do often define their own boolean types.
  • ardy42 6y ago
    > YAML has 22 ways to write booleans - no less! > I would argue that XML, in practice, has many more. Everything in XML is a string by default, and only an XSD can provide actual type information. Lots of things don't, and those that do often define their own boolean types. I think the problem happens when there are 22 ways to write them in the standard and you only know 16 of them (or 27 of them). You're going to be surprised (by the standard) at some point. If the standard doesn't define anything, then you at least know the responsibility for the definition is between you and your integrations, so at least you won't be surprised by the standard itself. As far as standard representations go I think the ideal numbers are 0 and 1: either it should define nothing or pick one unambigous standard representation.
• nlte 6y ago
  Ten years ago, I loved XML mainly because of what I could do with XSLT, and I wrote many websites where the data were XML (static files) and the XSLT scripts acted as the views to output HTML. All that was server-side (ASP or PHP). The equivalent for me today is JSON for then data and the Lodash library to transform them. The environment has switched to JavaScript (Node.js + browser), which was a tremendous improvement. For me, Lodash is the new XSLT - all about data transformation - although they're conceptually unrelated.
• fergie 6y ago
  The author forgot to mention one the biggest functional benefits of XML which is interpolation: the ability to drop XML components into the middle of text, thereby allowing for markup and nesting of elements in text. <tag> This text node contains <magic>unicorns</magic> and <magic>fairy dust</magic>. </tag> There is (as far as I know) no sensible way to add the magic above in JSON or YAML.
  • chrisoverzero 6y ago
    >[…] the ability to drop XML components into the middle of text, thereby allowing for markup and nesting of elements in text. Is that “allowing” for markup, or is it exactly what an Extensible Markup Language was intended and designed to do? I wouldn’t expect a JavaScript Object Notation to be able to do that ergonomically. XML’s design as a markup language, and not an object or config language, is clear even in that example. The first character of the contents of `tag` is newline.
  • kanox 6y ago
    This example should that XML is decent as markup but for a configuration or data interchange format this kind of syntax is undesirable. You have text with interspersed elements with the same name, how can this be represented in python other than a DOM?
    • SamWhited 6y ago
      One of the other benefits of XML the author mentions solves this: if you don't want it, disallow it in your schema.
      • kanox 6y ago
        If I disallow everything I don't want from XML I just end up with a more verbose json that is harder to work with.
        • SamWhited 6y ago
          That's fine, then XML wouldn't be the proper tool for you and you shouldn't be using it, but I was responding to someone saying that they didn't want a specific thing (non-text inside certain tags) which XML supports.
• ajxs 6y ago
  Here's a fantastic article about the various misuses of XML that I greatly enjoyed: https://www.devever.net/~hl/xml https://www.devever.net/~hl/xml
• fetbaffe 6y ago
  In the old days many things that were XML when it should have been JSON, today it is the opposite, many things that are JSON when it should be XML.
• ivolimmen 6y ago
  I so agree with this. I have been complainging in different companies that using REST is not practical between application (at least use JSON-API then). REST is usefull for frontend <-> backend communication. SOAP was horrible simetimes but it worked. If you change the contract the clients simply do not compile. This is not the case when you change a service using REST (yeah there are some fixes for that but they are not common and widely used).
  • dragonwriter 6y ago
    > I have been complainging in different companies that using REST is not practical between application (at least use JSON-API then). JSON-API is REST, though not all REST is JSON-API. > REST is usefull for frontend <-> backend communication. Actual REST is least useful for communication between a single frontend and backend controlled by the same party. > SOAP was horrible simetimes but it worked. More accurately, SOAP was horrible and it sometimes worked. > If you change the contract the clients simply do not compile. I’m not sure how that would be a good thing, even if it were true, which it isn't unless you are fetching the WSDL and then recompiling clients each time you try to access the server. > This is not the case when you change a service using REST Which is a good thing, HATOEAS plus resources described with media types and using content-type and accept headers properly, all of which is part of REST over HTTP, give you plenty of opportunity for clean error for a representation change you can't handle without requiring you to try compiling at each access.
    • theSIRius 6y ago
      > Actual REST is least useful for communication between a single frontend and backend controlled by the same party. I know I'm going off-topic but what is best way to communicate between frontend and backend except for REST? I know about GraphQL even though that is not widely adopted yet and in a lot of cases never will be.
• indymike 6y ago
  I've been involved in XML standards making for about seven years, and one of the things I'm most proud of is encouraging the standards body to publish a JSON standard. XML is extremely flexible, and delivered on being extensible. That is why it has fallen out of favor. XML is pretty unforgiving in terms of what is valid (this is all for good reason) and the extensibility brings with it a lot of complexity. XML is: - Complex and requires tools with more functionality than, say JSON. Yes other formats do less. That is why formats like JSON are supported completely in most languages and XML and it's dependent standards. For example SOAP is not fully supported by Python. - Brittle. It is easy to introduce errors in XML that cause most XML parsers to fail. Bad characters, bad or missing escapes, unbalanced tags all introduce points of failure. - XML is the foundation of even more brittle and complex standards like SOAP and XHTML. Yes, SOAP is really cool. WSDLs when supported are magic. But... when something isn't right, it's very difficult to fix or get working. Meanwhile, a mediocre developer can integrate with a web api that delivers JSON in an hour or two. While XML can do the job, JSON, YAML and TOML all are a lot smaller in terms of tooling and cognitive overhead, and most importantly, writing a library to handle them is much less daunting than supporting XML and all of it's child standards. All that said, for more complex data interchange cases, and internal file formats, XML still is hard to beat. So much work is done for you.
  • wsc981 6y ago
    Whenever someone mentions SOAP I’m always reminded about this funny article “S Stands For Simple” [0]. ——— [0]: http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple
    • dfox 6y ago
      It is "Simple" in contrast to things like CORBA and DCOM. Which it accomplishes by not solving the main problem that these distributed object protocols try to solve at all and instead being overly complex RPC protocol with completely unnecessary "object orientation". On a similar note, the L in LDAP stands for lightweight, which was accomplished by removing advanced authentication features from X.500 DAP and then gradually reimplementing the same functionality with significantly more complex "simple" "framework" that in theory allows usage of any conceivable authentication mechanism, or something like that.
• gnufx 6y ago
  I don't see a reference to Siméon and Wadler: "So, the essence of XML is this: the problem it solves is not hard, and it does not solve the problem well." http://homepages.inf.ed.ac.uk/wadler/papers/xml-essence/xml-essence.pdf http://homepages.inf.ed.ac.uk/wadler/papers/xml-essence/xml-...
• 60secz 6y ago
  XML did many things right and a few big things wrong. It's a tragedy there isn't a single imple, standardized way to define an array through xml as there is through json. The lack of schema validation in json is equally baffling. A hack for JSON comments { "//": "Comment1", ... "//": "Comment2" }
  • sharpercoder 6y ago
    Json-schema.org
  • dragonwriter 6y ago
    > The lack of schema validation in json is equally baffling. XML schema languages, like those for JSON—of which there are many, again as is the case for JSON—appeared after the format had wide adoption, and are separate from the base standard. I'm not sure what distinction you are trying to draw here, because I don't really see one.
• Mikhail_Edoshin 6y ago
  XML is in a totally different category than JSON: it's a tool to craft formal languages. A data format or a config is also a language of sorts, so it can do that as well, but it's real purpose are languages in general. XML languages are what is left of a language if you omit parsing and start with AST. Configs and data formats normally don't require all the benefits of a language (e.g. composability), but other things do, e.g. UI systems.
• patrec 6y ago
  This is terrible advice. Exposing any public endpoint that talks XML is a security disaster in waiting and the fact that the author makes no mention of a long history of major security vulnerabilities in popular XML packages does no credit to him. The "composable" without "confusion about semantics" is a joke, too: in practice it's not even possible to know what whitespace means. Is it semantically meaningful or just there for pretty printing? Also, say you see a commented out region in an XML file. How do you uncomment it? If XML where less braindamaged both problems would be trivial and purely mechanical. In practice you'll generally have to guess. All in all XML is an extremely mediocre design: it is substantially worse than prior art in countless respects and tremendously complicated without achieving much of anything.
  • jerome-jh 6y ago
    Indeed. Although XML has a grammar its complexity led to countless flawed implementations. The original sin of XML is that it has been over-hyped from the beginning. Is it the cause or the consequence of it being over-engineered, I would not say. Anyway following standards, XLST, XPath, saw poor adoption. I am not fond of JSON and YAML either, but since they are much less ambitious, I am somewhat more forgiving with them. None of them is good at being a config file format. None one them is good at data serialization, that should be binary and TLV encoded.
  • WesolyKubeczek 6y ago
    > it is substantially worse than prior art in countless respects The prior art being? ASN.1 libraries don't have a stellar security track record either. Flexible data interchange is _hard_.
    • patrec 6y ago
      XML is basically just a vastly inferior form of sexps, just as ASN.1 at least for the purposes of encoding cert info in TLS is vastly inferior to csexps -- the latter is canonical by design, efficient and trivial to write a robust parser for.
      • 6y ago
• tester34 6y ago
  XML is great for interfaces, ain't it?
• nickbauman 6y ago
  I think the problem with XML is that people tried to make it into something as comprehensive as CORBA (this is SOAP) so that all the decisions about the communication was done in-band. JSON requires everyone to make out-of-band decisions about what the JSON should look like: people talking to each other, imagine that! The former seems quaintly antisocial nowadays.
• piercebot 6y ago
  Surprised that nobody has brought up size over the wire yet. XML, by virtue of the fact that it has both opening and closing tags, tends to be more verbose than other standards. With larger requests, this can translate to hundreds of extra kilobytes transferred. Even for smaller requests, people in bandwidth-constrained environments will probably notice performance improvements when using a more concise standard over XML.
  • hobs 6y ago
    Especially for repetitive files, I did some testing for an ETL process that was effectively "here's multiple CSVs in an XML file" - break that into multiple csvs (which matched the customer expectations anyway) and got 30x savings in size.
    • MereInterest 6y ago
      How much of this is effectively making a custom compression scheme? Would you get better compression by using the gzip compression of HTTP?
      • hobs 6y ago
        That's a fair point, but I am talking just zip compression comparisons, not http actually.
  • theandrewbailey 6y ago
    XML's verbosity is solved with compression. Your webserver is configured to compress text-based formats, right?
• rjkennedy98 6y ago
  I think his notes about performance miss the full picture. Obviously gzipped XML and JSON aren't going to cause network slowness, but I've been on big projects that use XML as a data interchange format and XML marshalling and unmarshalling with validation was a bottleneck in the system. We used JAXB and loading the hundreds and hundreds of schemas in JBoss was so expensive that they had to bump up the memory to 32 gb on our personal computers. In the end XML schema validation had to be turned off (removing the whole point of it). Also, this was Java which is compiled and obviously very fast. Can you imagine the same thing in PHP or Python? It would be impossible. I'd be curious if the author ever did a large XML project in a dynamic programming language. I seriously suspect not and these languages (PHP, Node, Python) are the most popular and productive languages in the world. XML is good at some specific things, but as a general use data-interchange format it is dead as a doornail and there is no good reason to bring it back.
  • fetbaffe 6y ago
    Most common XML parsers in PHP uses libxml which is written in C, so it should be relatively fast, however I haven't used it for super large XML-files and not for every request. It would be interesting to test.
• textman 6y ago
  XML was designed for documents, not data. By document I mean large amounts of text. It came out of the publishing industry. In that context, the tags end up comprising an insignificant portion of the total document, so is not overly verbose.