5 ms·

It's just because XML is a bad choice. It's a standard for creating markup languages, but use in HTML failed because it's more verbose and doesn't cope at all w

It's just because XML is a bad choice. It's a standard for creating markup languages, but use in HTML failed because it's more verbose and doesn't cope at all with user errors. For data serialisation it's just insane. The only reason to use XML to serialize your non markup data is that it's a web technology and you have parsers everywhere. Mapping data back and forward between your data structures and the XML representation is a huge pain in the ass, as there's no natural mapping. For some formats like SVG you basically have to keep data as a DOM in your program. > And while XML is complicated there are far more complicated formats (YAML). While the Syntax of YAML certainly is more complicated, totally I would say that it's less complicated without all the XPath, Namespaces etc. you additionally need. YAML maps fairly direct to data structures of programs and the complexity is there to get human readability and edit ability. Something XML doesn't have when used for general data. > TOML Is basically just a specification of the largely unspecified INI format, which is older than XML. This is just a format for human editable configuration files, for which we have experience that XML really really sucks. > JSON Very simple data format that maps directly to data structures of all common programming languages. The fact that JSON beat XML where XML is at home, in the web shows pretty clearly that JSON is the better format for data serialisation. TL;DR: Use the correct format for the use case. XML is for markup, not serialisation. JSON is for serialisation, YAML is a better readable JSON e.g. if you mainly use the data for debugging, INI(/toml) is for configuration files.

agentgt 11y ago
While I think we are on the same page (I did say XML has strength and weaknesses) I think XML is undervalued for a configuration language particularly if the configuration language is to be modified by another application or script. The reason a markup language like XML is actually sort of useful for a configuration is that spacing and comments can be preserved on modification. That is if I modify the XML manually and then modify it with a script (assuming the script is written correctly) I can preserve my formatting and my comments. As far as I understand such is not the case with many formats (I suppose YAML would be the exception albeit I'm not sure if it preserves white space other than the required whitespace). I have actually had this use come up. I had 20 or so Maven POM files that I had to modify/refactor. It was fairly easy to do because it was XML all while preserving the formatting and comments. With the exception of massively complex configuration (aka Ansible) I really don't think most users (particularly non-techy) care that XML is slightly more verbose than YAML. Particularly since configuration is not modified that often and again its like HTML (although HTML is a failure technology wise it is ubiquitous). As for serialization... XML is bad... I can't come up with any devils advocation for that.
chipsy 11y ago
At the core of XML you can still see the SGML origins. It is great stuff if you have an actual document to work on - like, documentation, or an essay, or a manual... there are some very comprehensive schemas and renderers around for those use cases, that can do heavy lifting where Markdown or Word start failing you, and TeX is inappropriate. What polluted XML the most was simply being overhyped, especially as "human-readable". It's not binary, but it's also not a good front end for any human task. Although it's capable of flexible markup, that makes it an inefficient source format. Even in the case where you have a document to write, it can be more palatable to parse something simpler and convert it, and then apply finishing touches to the XML where the precision works in your favor. That said, most data is not really a document, but a tiny fragment with relations. Documents only make sense once you have some kind of story to tell.

agentgt 11y ago

While I think we are on the same page (I did say XML has strength and weaknesses) I think XML is undervalued for a configuration language particularly if the configuration language is to be modified by another application or script. The reason a markup language like XML is actually sort of useful for a configuration is that spacing and comments can be preserved on modification. That is if I modify the XML manually and then modify it with a script (assuming the script is written correctly) I can preserve my formatting and my comments. As far as I understand such is not the case with many formats (I suppose YAML would be the exception albeit I'm not sure if it preserves white space other than the required whitespace). I have actually had this use come up. I had 20 or so Maven POM files that I had to modify/refactor. It was fairly easy to do because it was XML all while preserving the formatting and comments. With the exception of massively complex configuration (aka Ansible) I really don't think most users (particularly non-techy) care that XML is slightly more verbose than YAML. Particularly since configuration is not modified that often and again its like HTML (although HTML is a failure technology wise it is ubiquitous). As for serialization... XML is bad... I can't come up with any devils advocation for that.

chipsy 11y ago

At the core of XML you can still see the SGML origins. It is great stuff if you have an actual document to work on - like, documentation, or an essay, or a manual... there are some very comprehensive schemas and renderers around for those use cases, that can do heavy lifting where Markdown or Word start failing you, and TeX is inappropriate. What polluted XML the most was simply being overhyped, especially as "human-readable". It's not binary, but it's also not a good front end for any human task. Although it's capable of flexible markup, that makes it an inefficient source format. Even in the case where you have a document to write, it can be more palatable to parse something simpler and convert it, and then apply finishing touches to the XML where the precision works in your favor. That said, most data is not really a document, but a tiny fragment with relations. Documents only make sense once you have some kind of story to tell.