7 ms·

Well, XML is a markup language (and is really good at being that) while JSON is not. Sure, XML can be used as a poor man's data storage, as a base for a DSL, et

Well, XML is a markup language (and is really good at being that) while JSON is not. Sure, XML can be used as a poor man's data storage, as a base for a DSL, etc., but almost always there are better choices.

jeremyjh 7y ago
You aren't responding to the comment here, you are just reasserting the article's position. I'd argue there is not another format that is obviously better for every data storage or exchange use case, or that surpasses all of XML's benefits while minimizing all of its downsides. I don't want to look at XML, but I do understand why it is being used.
- deleted 7y ago
  [deleted]
- gambler 7y ago
  Abuse of XML killed it a format. JSON is absolutely shit for semantic markup, and yet developers today routinely use it for documents because "XML is bad". They contrive ridiculous schemes for adding metadata and type information. They use it to generate HTML even when HTML takes less space. Finally, we regressed from XTML to HTML5. Buy-buy namespaces and parsing consistency.
  - sedachv 7y ago
    SGML being replaced by XML being replaced by JSON is great proof that the idea of progress in tech is at best a myth and at worst a lie.
    - barberousse 7y ago
      I mean, the idea of progress in general is barely agreeable outside of recent strides in the physical sciences
  - myrryr 7y ago
    Right, but, if given a choice of what to use, between XML and JSON, I'll pick JSON every time. XML is a complete mess. Have you SEEN it's spec? You can put JSONs spec in a single page. XMLs spec, not so much. Hell, most of the XML parsers don't support the spec, and the ones which do, historically have been riddled with security holes. JSON over XML was simplicity over a crazy spec built by a bunch of companies all wanting to shove their own crazyness into it.
    - sedachv 7y ago
      http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php https://en.wikipedia.org/wiki/JSON#Data_portability_issues https://en.wikipedia.org/wiki/JSON#Data_portability_issues XML has XSD and RELAX NG for more than 15 years now. https://json-schema.org/ https://json-schema.org/ is still a draft.
    - Mikhail_Edoshin 7y ago
      XML spec is longer than one page, granted, but it's about three times shorter than YAML spec. And XML spec describe not only the XML syntax, but also a basic form of validation (DTD), which include references. Basic XML has only five special symbols (<, >, ', ", and &) and can be parsed in linear time. (Namespaces complicate things somewhat.)
    - alkonaut 7y ago
      For a non human-edited data storage or exchange that’s fine. Json is worse for human editable data though. Xml might not be the best alternative there but it beats json for things like small configs. It’s not as simple as saying “everywhere xml is used, json would be a better choice”.
    - jackcviers3 7y ago
      That's because json's spec isn't complete. It is predicated on the language interpreting it to be able to just eval the structure and work with the data [1] 1. http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php
  - redwall_hp 7y ago
    > They use it to generate HTML even when HTML takes less space. The fact that MobileDoc exists makes me physically ill. Something that can be expressed with one line containing a paragraph element and an italic tag is over a dozen lines of JSON spam.
- jackcviers3 7y ago
  Your data storage format shouldn't be human readable. The data transferred over the wire shouldn't be human readable. It should be a binary serialized data format, probably encrypted, definitely compressed. Yes, storage is cheap. Bandwidth is not. Also, you really don't want a human that intercepts your data to be able to read it. Additionally, your data structue only makes sense in the context of your domain, which usually has been modeled in your program(s) that work in that domain, and thus it will be better if you deserialize it within tools that understand that domain. If you feel the need for a general purpose deserialization protocol, there are several available - Avro/Protobuf, etc. Binary encoded data can often be decoded without consuming the entire document. Sax-paparser-like reading requires at least reading an open and a close before the data is useful. String serialization is a wasteful endeavor. It makes life easy for devs because it takes one less step to read the data in a text editor or log message, but quite often requires hacks to model things like recursive or self-referential data structures, and wastes space by repeating property names constantly for every item within the serialized structure. It's predicated on four of the fallacies of distributed computing, namely - bandwidth is infinite, the network is secure, transport cost is zero, and latency is zero. It is a solution looking for a problem, and because we are lazy, we don't build tools that would make binary serialized formats just as easy to use as json/yaml/xml.
arkitaip 7y ago
Yet every time I've stumbled upon XML in the past decade or so It's been used as a data format because it's easy to manage and supported by every platform/tool out there. But sure, let's switch over to JSON or use a SQL database because we can't deal with the fact that XML might be better suited for something that it wasn't originally designed for.
alkonaut 7y ago
What are the better choices? And what were the better choices on the major platforms 10 years ago, the choice of which would have not seen every app use xml config files/dls/storage now? I use csv when applicable. I use protobufs when applicable. But for the typical use case I choose xml for it's some config/dsl/dataset that needs to be human-editable (support comments, for example), more complex structure than csv supports, and preferably not need an external library or a custom parser. Json, Csv, Toml, S-Expressions, protobufs all fail one of more of these requirements. I'm sure there are others but none that don't have at least one drawback I don't want. A poor man's data storage is exactly what I want!.
- democracy 7y ago
  and having schemas is also great for some cases
  - EdwardDiego 7y ago
    Schemas are awesome for so many cases. Even though JSON Schema is a giant evolving clusterfuck, I still use it to be able to enforce some consistency. And, being honest, JSON schema is better than, say, GPB or Avro schema at enforcing field relationships, e.g., "if typeId is 7, then partnerId cannot be null"
- yellowapple 7y ago
  > preferably not need an external library or a custom parser. Json, Csv, Toml, S-Expressions, protobufs all fail one of more of these requirements. And XML doesn't? Quite a few (not all, but quite a few nonetheless) programming languages include zero support for reading or writing XML-formatted data without using an external library or custom parser. This includes nearly all languages that predate XML, and quite a few languages that postdate it. Even when a language does have built-in (or at least in the standard library) support for XML, it's almost always a royal pain to use, especially once namespaces and schemas are involved. Once upon a time, though, the answer was (and in a lot of places still is) INI: - It's human-editable and supports comments - It supports more complex structure than CSV - Some languages have built-in support for it, and the Windows and GLib APIs support it, too (well, something similar enough to be compatible, in the latter case) INI falls flat when you need to express deeper levels of nesting than keys and sections, though. There's also YAML, which meets all your criteria about as well as XML does (at least on average; your specific language/platform might favor one or the other).
ljm 7y ago
It doesn’t answer the question, but I do wonder if XML would be an improvement in devops, compared to the current obsession with YAML. For everything except the part where you write it. Make an xml stylesheet and your kubernetes cluster is instantly documented.
- RantyDave 7y ago
  XML is pretty horrible to edit by hand.
  - sedachv 7y ago
    Maybe if you are using Notepad. Any decent text editor will provide things like auto indentation, completion, auto end-tags, structured editing, and schema validation. For example, Emacs comes with nXML mode: https://www.gnu.org/software/emacs/manual/html_mono/nxml-mode.html https://www.gnu.org/software/emacs/manual/html_mono/nxml-mod...
    - theamk 7y ago
      That assumes that you edit XML all day long. This is not always the case. I am writing non-XML code most of the day, and I do not have structured editing / auto braces enabled. So when I need to edit that one XML config, I'll open it in my regular editor, which will provide at most syntax highlight, and edit it as needed with a bit of swearing. And next time, I would promise myself I'd choose a different config format which does not need special editors.
      - Mikhail_Edoshin 7y ago
        xmllint --noout <file> will check the file and report any issues with XML syntax in a very detailed way with line numbers for you to see. I myself don't even use syntax highlighting and normally work in vim and although I do make errors in XML sometimes, I find that I make at least as many syntactic errors in Python or C code that I have to weed out before I can proceed. But I never heard anyone complaining about Python or C being too strict :)
Mikhail_Edoshin 7y ago
Markup is a mix of scalar and structured data (it's a structure discovered or associated with a scalar) and thus it contains everything it needs to express structured data alone: just remove the scalar. E.g. <invoice id="123" customer-id="456" date="20199-10-30"> <item no="1" product-id="789" qty="42" /> </invoice> Is this really a poor man's choice? And compared to JSON?! I can see at least the following advantages here: 1. Each element has explicit type name (invoice, item). JSON is "typeless", which simply means the type information travels out of band. And with XML namespaces these type names can be made globally unique, but still stay human readable. 2. Each element is self-contained, the code that produces the <item> doesn't need to know if there was an item before or after it so that it should add a separator. (The dangling comma problem in JSON.) 3. The attribute names are not just arbitrary strings as in JSON, there are strict rules of what can be in the name. They're much more suited for structured data than JSON, where you can name an attribute "foo.bar" and some JSON readers that accept a JSON "path" won't be able to find it. 4. It has less visual noise than JSON because the attributes don't have quotes around them and you don't need to separate elements with a special symbol. Despite the common belief well-written XML is more readable than JSON. And we haven't event touched things like validation + extended types, references, and transformation of data.

jeremyjh 7y ago

You aren't responding to the comment here, you are just reasserting the article's position. I'd argue there is not another format that is obviously better for every data storage or exchange use case, or that surpasses all of XML's benefits while minimizing all of its downsides. I don't want to look at XML, but I do understand why it is being used.

deleted 7y ago
[deleted]
gambler 7y ago
Abuse of XML killed it a format. JSON is absolutely shit for semantic markup, and yet developers today routinely use it for documents because "XML is bad". They contrive ridiculous schemes for adding metadata and type information. They use it to generate HTML even when HTML takes less space. Finally, we regressed from XTML to HTML5. Buy-buy namespaces and parsing consistency.
- sedachv 7y ago
  SGML being replaced by XML being replaced by JSON is great proof that the idea of progress in tech is at best a myth and at worst a lie.
  - barberousse 7y ago
    I mean, the idea of progress in general is barely agreeable outside of recent strides in the physical sciences
- myrryr 7y ago
  Right, but, if given a choice of what to use, between XML and JSON, I'll pick JSON every time. XML is a complete mess. Have you SEEN it's spec? You can put JSONs spec in a single page. XMLs spec, not so much. Hell, most of the XML parsers don't support the spec, and the ones which do, historically have been riddled with security holes. JSON over XML was simplicity over a crazy spec built by a bunch of companies all wanting to shove their own crazyness into it.
  - sedachv 7y ago
    http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php https://en.wikipedia.org/wiki/JSON#Data_portability_issues https://en.wikipedia.org/wiki/JSON#Data_portability_issues XML has XSD and RELAX NG for more than 15 years now. https://json-schema.org/ https://json-schema.org/ is still a draft.
  - Mikhail_Edoshin 7y ago
    XML spec is longer than one page, granted, but it's about three times shorter than YAML spec. And XML spec describe not only the XML syntax, but also a basic form of validation (DTD), which include references. Basic XML has only five special symbols (<, >, ', ", and &) and can be parsed in linear time. (Namespaces complicate things somewhat.)
  - alkonaut 7y ago
    For a non human-edited data storage or exchange that’s fine. Json is worse for human editable data though. Xml might not be the best alternative there but it beats json for things like small configs. It’s not as simple as saying “everywhere xml is used, json would be a better choice”.
  - jackcviers3 7y ago
    That's because json's spec isn't complete. It is predicated on the language interpreting it to be able to just eval the structure and work with the data [1] 1. http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php
- redwall_hp 7y ago
  > They use it to generate HTML even when HTML takes less space. The fact that MobileDoc exists makes me physically ill. Something that can be expressed with one line containing a paragraph element and an italic tag is over a dozen lines of JSON spam.
jackcviers3 7y ago
Your data storage format shouldn't be human readable. The data transferred over the wire shouldn't be human readable. It should be a binary serialized data format, probably encrypted, definitely compressed. Yes, storage is cheap. Bandwidth is not. Also, you really don't want a human that intercepts your data to be able to read it. Additionally, your data structue only makes sense in the context of your domain, which usually has been modeled in your program(s) that work in that domain, and thus it will be better if you deserialize it within tools that understand that domain. If you feel the need for a general purpose deserialization protocol, there are several available - Avro/Protobuf, etc. Binary encoded data can often be decoded without consuming the entire document. Sax-paparser-like reading requires at least reading an open and a close before the data is useful. String serialization is a wasteful endeavor. It makes life easy for devs because it takes one less step to read the data in a text editor or log message, but quite often requires hacks to model things like recursive or self-referential data structures, and wastes space by repeating property names constantly for every item within the serialized structure. It's predicated on four of the fallacies of distributed computing, namely - bandwidth is infinite, the network is secure, transport cost is zero, and latency is zero. It is a solution looking for a problem, and because we are lazy, we don't build tools that would make binary serialized formats just as easy to use as json/yaml/xml.

arkitaip 7y ago

Yet every time I've stumbled upon XML in the past decade or so It's been used as a data format because it's easy to manage and supported by every platform/tool out there. But sure, let's switch over to JSON or use a SQL database because we can't deal with the fact that XML might be better suited for something that it wasn't originally designed for.

alkonaut 7y ago

What are the better choices? And what were the better choices on the major platforms 10 years ago, the choice of which would have not seen every app use xml config files/dls/storage now? I use csv when applicable. I use protobufs when applicable. But for the typical use case I choose xml for it's some config/dsl/dataset that needs to be human-editable (support comments, for example), more complex structure than csv supports, and preferably not need an external library or a custom parser. Json, Csv, Toml, S-Expressions, protobufs all fail one of more of these requirements. I'm sure there are others but none that don't have at least one drawback I don't want. A poor man's data storage is exactly what I want!.

democracy 7y ago
and having schemas is also great for some cases
- EdwardDiego 7y ago
  Schemas are awesome for so many cases. Even though JSON Schema is a giant evolving clusterfuck, I still use it to be able to enforce some consistency. And, being honest, JSON schema is better than, say, GPB or Avro schema at enforcing field relationships, e.g., "if typeId is 7, then partnerId cannot be null"
yellowapple 7y ago
> preferably not need an external library or a custom parser. Json, Csv, Toml, S-Expressions, protobufs all fail one of more of these requirements. And XML doesn't? Quite a few (not all, but quite a few nonetheless) programming languages include zero support for reading or writing XML-formatted data without using an external library or custom parser. This includes nearly all languages that predate XML, and quite a few languages that postdate it. Even when a language does have built-in (or at least in the standard library) support for XML, it's almost always a royal pain to use, especially once namespaces and schemas are involved. Once upon a time, though, the answer was (and in a lot of places still is) INI: - It's human-editable and supports comments - It supports more complex structure than CSV - Some languages have built-in support for it, and the Windows and GLib APIs support it, too (well, something similar enough to be compatible, in the latter case) INI falls flat when you need to express deeper levels of nesting than keys and sections, though. There's also YAML, which meets all your criteria about as well as XML does (at least on average; your specific language/platform might favor one or the other).

ljm 7y ago

It doesn’t answer the question, but I do wonder if XML would be an improvement in devops, compared to the current obsession with YAML. For everything except the part where you write it. Make an xml stylesheet and your kubernetes cluster is instantly documented.

RantyDave 7y ago
XML is pretty horrible to edit by hand.
- sedachv 7y ago
  Maybe if you are using Notepad. Any decent text editor will provide things like auto indentation, completion, auto end-tags, structured editing, and schema validation. For example, Emacs comes with nXML mode: https://www.gnu.org/software/emacs/manual/html_mono/nxml-mode.html https://www.gnu.org/software/emacs/manual/html_mono/nxml-mod...
  - theamk 7y ago
    That assumes that you edit XML all day long. This is not always the case. I am writing non-XML code most of the day, and I do not have structured editing / auto braces enabled. So when I need to edit that one XML config, I'll open it in my regular editor, which will provide at most syntax highlight, and edit it as needed with a bit of swearing. And next time, I would promise myself I'd choose a different config format which does not need special editors.
    - Mikhail_Edoshin 7y ago
      xmllint --noout <file> will check the file and report any issues with XML syntax in a very detailed way with line numbers for you to see. I myself don't even use syntax highlighting and normally work in vim and although I do make errors in XML sometimes, I find that I make at least as many syntactic errors in Python or C code that I have to weed out before I can proceed. But I never heard anyone complaining about Python or C being too strict :)

Mikhail_Edoshin 7y ago

Markup is a mix of scalar and structured data (it's a structure discovered or associated with a scalar) and thus it contains everything it needs to express structured data alone: just remove the scalar. E.g. <invoice id="123" customer-id="456" date="20199-10-30"> <item no="1" product-id="789" qty="42" /> </invoice> Is this really a poor man's choice? And compared to JSON?! I can see at least the following advantages here: 1. Each element has explicit type name (invoice, item). JSON is "typeless", which simply means the type information travels out of band. And with XML namespaces these type names can be made globally unique, but still stay human readable. 2. Each element is self-contained, the code that produces the <item> doesn't need to know if there was an item before or after it so that it should add a separator. (The dangling comma problem in JSON.) 3. The attribute names are not just arbitrary strings as in JSON, there are strict rules of what can be in the name. They're much more suited for structured data than JSON, where you can name an attribute "foo.bar" and some JSON readers that accept a JSON "path" won't be able to find it. 4. It has less visual noise than JSON because the attributes don't have quotes around them and you don't need to separate elements with a special symbol. Despite the common belief well-written XML is more readable than JSON. And we haven't event touched things like validation + extended types, references, and transformation of data.