I’m going to just argue the exact opposite of the article: xml and json are both structured data formats useful for tree like data graphs, such as objects.<p>Whether that was the intended purpose when xml was designed is irrelevant. It’s what xml is used for in almost every case.<p>The author also doesn’t suggest what should be used instead to encode structured data, or perhaps more importantly what <i>should</i> have been used to encode graph like things such as map/lists/objects in the 2000’s. Json really hasn’t been an alternative until quite recently (10 years ago?).<p>In fact reading the article carefully I fail to see the author argue <i>why</i> xml shouldn’t be used as a data format either.
So, what <i>is</i> XML good for? If it's not good for data as everyone says (and I'm not inclined to argue), but it is good for documents, what kind of documents are we referring to? A defined metadata on a text document? A template used with data to generate something else? Is a configuration file a document or data? Where would I want to use XML that something like JSON, a text document, or some combination thereof wouldn't be better?<p>I'm not being facetious, this is an honest question. Where are the "right" places to use XML?
That's a very useful and sobering view actually. Unfortunately for the XML format it wasn't designed to prevent its own abuse. But anyway, <i>XML is for documents</i> sounds like a good and acceptable paradigm.<p>That being said, one subtle and important (and often overlooked) difference between XML and, say JSON is that you can stream XML while parsing it on the application level, whereas JSON can not be parsed by the application due to arbitrary ordering of keys. (Of course lower level parsers use streaming anyway, but that's not the point)<p>In fact you not only can but you should parse XML while streaming it. This is another common abuse: wherever you look you see some high level function that loads an entire parsed XML structure into memory at once. But once you start asking yourself where the file may be coming from you realize that your system may be open to denial of service attacks. E.g. is your system ready to receive a 16GB XML file?
XML is a actually wonderful format for data and especially extensible configuration if you combine it with XML Schema and CSS selectors...<p>- XML schemas give you a ready-to-use format to describe, restrict and document available configuration settings. The unique keys help and a libxml2 gives ready to use validation, even if you may need to 'translate' its error messages before showing them to end users<p>- XML schemas also support other annotations so you can further generalise your configuration readers by recording the necessary bindings in the XML schema itself, allowing to use it eg to define application user interfaces.<p>- Almost any text editor can do basic syntax validation preventing most typographic errors, and even better if they can read the schema<p>- XML schemas are extensible using <import>s, but namespaces still enforce some separation. You can define explicit points where plugins extend your configuration format using <any><p>- Human editable - closing tags are noisy but more readable than }],{}] when non-programmers may have to edit these files just to add a few extra textfields to an UI.<p>- Better datatype support, eg datetimes, by using XML schemas. JSON's type support is too limited<p>- Support for comments!<p>- And once you've verified the schema... CSS selectors and DOM APIs to actually process the XML documents.<p>YAML fixed quite a few things, but still no date times or as far as I know standardised approaches to defining schemas. And I've lost count at how any attempts exist to add schema information or namespacing to JSON...<p>But for markup... we may be better off to just use markdown inside CDATA blocks
> Here are some very frequently occurring examples of bad schema design:<p>(4 lines, 75 characters)<p>> Here's the right way:<p>(10 lines, 133 characters)<p>I have a suspicion as to what went wrong.
One thing this misses in the "dictionary" example is that tools (like xpath) push you towards "key in attribute" selection. One of the most common operations we do with dictionaries is lookup by known key, and storing the key in attributes makes it much easier.
Can I have my gripe with apple plists?<p><key>CFBundleDisplayName</key><p><string>TextEdit</string><p><key>NSHumanReadableCopyright</key><p><string>Copyright 2019</string><p>This may be perfectly parsable by a SAX parser storing some state, but its totally not processable by xslt.
I guess the correct answer depends upon the requirement.<p>I like this way<p><pre><code> <root>
<item key="name">John</item>
<item key="city">London</item>
</root>
</code></pre>
So I can use this xpath to get the person's name:<p><pre><code> //root/item[@key="name"]/text()
</code></pre>
Not sure what would be the xpath to get the name if the XML was<p><pre><code> <root>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</root>
</code></pre>
This is a better example:<p><pre><code> <employees>
<employee id="1">
<field name="name">John</field>
<field name="city">London</field>
</employee>
<employee id="2">
<field name="name">Jack</field>
<field name="city">Boston</field>
</employee>
<employees></code></pre>
XML is/can be much more than a markup language and yes, it can be used very badly but this is usually by inexperienced 'data wranglers' who don't understand the difference between data attributes and data proper.<p>While XML can seem cumbersome (compared to JSON say) it is a very good 'data transport' tool when used correctly with a sensible schema (XSD).<p>For example, we use XML as a 'vendor neutral' data format to export/import CAD geometry and associated data for town utilities such as buildings, pipes, roads etc. All this data has to be validated against the schema to ensure its correctness.
Using a schema like this enables the city council to import this XML into the GIS system to be used for asset management, financial planning etc.<p>A good schema can be key to sharing XML effectively between departments/applications and being a markup language this data can also be viewed independently using XLST.
I agree with this portion 100%<p>The correct way to express a dictionary in XML is something like this:<p><root>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</root><p>In the past I used to create scripts that exported xml from relational data but didn't really understand the right way to build and structure them.
The larger your XML file is the more accurately you're using it. Less " and more <>. I made these mistakes, using XML like a I was writing an HTML doc.
It is difficult for me to see what the real issue is with examples given. It seems to be more an aesthetic preference of the author rather than a technical argument. People can use formats for whatever they want. :P<p>If you told me that the transmission and parsing rate is too slow for their application, that's a real dig at it.
For those wondering what you do with XML as a document markup language, see the XML document that is the specification for XML. I had to look at the page source to determine it really is an XML document. Looks like an HTML document.<p><a href="https://www.w3.org/TR/xml/REC-xml-20081126.xml" rel="nofollow">https://www.w3.org/TR/xml/REC-xml-20081126.xml</a>
I think that Software Engineers should take influence from Authors (after all, are we not all craftsmen/artisans?) and incorporate the philosophies from <a href="https://en.wikipedia.org/wiki/The_Death_of_the_Author" rel="nofollow">https://en.wikipedia.org/wiki/The_Death_of_the_Author</a><p>The idea, for those not familiar, is that once a work of art is published (a novel, a poem, a song, a painting), it speaks for itself, and authorial intent no longer matters.<p>That is, meaning and purpose are in the eye of the beholder/consumer. And there is no right or wrong way to "interpret" art. If someone finds meaning that the author did not intend, it is just as valid as a deeply hidden but intentional allegory they intentionally placed in when they were writing.<p>The relevance to software is it applies to APIs, specifications, standards and formats.<p>There is no such thing as users using your software or specification "wrong" - if they insist on doing so, the meaning has evolved. Evolve with it or die.
> <i>In 1996, XML was invented.</i><p>XML wasn't an original invention; it is specified as a proper SGML subset. From the XML spec:<p>> <i>The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document.</i><p>Now I totally agree that SGML and XML aren't for service payloads and config files. The sole purpose of markup languages is representing <i>structured text</i>. And arguably, SGML fills this role much more adequately than XML today as it can represent (via the SHORTREF mechanism) custom Wiki syntaxes such as markdown and others, and in contrast to XML, can deal with the largest corpus of markup out there eg. can parse HTML with all its minimization features such a omitted tags, enumerated and unquoted attributes, etc. See [1] for a practical introduction (disclaimer: link to a tutorial I held last month at ACM DocEng).<p>[1]: <a href="http://sgmljs.net/docs/sgml-html-tutorial.html" rel="nofollow">http://sgmljs.net/docs/sgml-html-tutorial.html</a>
turns out a well specified format that has a lot of parsers available is useful for more than just a markup language. xml is great at data formatting, a little more verbose than alternatives but also a lot more feature rich
I present, in the spirit of 'worst XML ever', the docs for ScriptXML:<p><a href="https://www.egosoft.com:8444/confluence/display/XRWIKI/Mission+Director+Guide" rel="nofollow">https://www.egosoft.com:8444/confluence/display/XRWIKI/Missi...</a><p>This is the language used in the game X4 Foundations (and others in the series). An example of its use (mine, i claim no grace in it):<p><a href="https://github.com/h2odragon/dragoncommands/blob/master/aiscripts/deployglobe.xml" rel="nofollow">https://github.com/h2odragon/dragoncommands/blob/master/aisc...</a><p>... XML is not a great format for an extension language, I have to say.
I would love to know what people think of my XML node-graph/tree editor I made before JSON became mainstream (my excuse): <a href="http://rupy.se/logic.jar" rel="nofollow">http://rupy.se/logic.jar</a><p>It basically names the tag what you name the node. :S<p>- You link/unlink nodes (I called them entities! Xo) by right-click-dragging between them.<p>- You copy stuff by right-click-dragging to an empty space.<p>- You delete by grabbing something by left-click-holding and pressing the delete key.<p>- Oh, and nodes are completely tree structure expandable, just drag-drop attributes on nodes and nodes inside nodes.<p>The editor uses lightweight rendering so you can have a ton of elements with good performance.<p>(I know, not super intuitive; but very handy once you know about these.)
> a simple test for determining if an XML schema is well designed: remove all tags and attributes from it ... If what you have left over does not make sense ... you shouldn't be using XML at all.<p>Magento 2 (acquired by Adobe for $1.68bn) uses XML to render its layouts. Here's some fun XML for the checkout page:<p><a href="https://github.com/magento/magento2/blob/2.3-develop/app/code/Magento/Checkout/view/frontend/layout/checkout_index_index.xml" rel="nofollow">https://github.com/magento/magento2/blob/2.3-develop/app/cod...</a>
I once had to write a data layer in xml, in-situ with a lifespan for up to hours, as more data was appended to it. An invalid xml document that you couldn't load in many xml apis for 99.9% of its lifespan.
I begged and pleaded the lead architect to use an sqlite db for the elements of the data until the transaction was complete and then merely produce the xml file at the end, but no.<p>It had to survive power outs too.
The worst XML use I have ever seen are lists generated by Lazarus. Every list. For example in the project files you have:<p><pre><code> <RequiredPackages Count="5">
<Item1>
<PackageName Value="LazUtils"/>
</Item1>
<Item2>
<PackageName Value="treelistviewpackage"/>
</Item2>
<Item3>
<PackageName Value="internettools"/>
</Item3>
<Item4>
<PackageName Value="LCLBase"/>
<MinVersion Major="1" Release="1" Valid="True"/>
</Item4>
<Item5>
<PackageName Value="LCL"/>
</Item5>
</RequiredPackages></code></pre>
Hmm...somewhat disagree with the "correct" way to express a dictionary. I prefer:<p><pre><code> <root>
<Name>John</Name>
<City>London</City>
</root>
</code></pre>
Removes one level of indirection, XML already has keys.
I have always thought that using XML as a format for storing and retrieving configuration files, was complete insanity.<p>Which is why I still use the simple, effective, INI format for configuration files for applications I write.<p>XML for config files is madness personified.
RIP Eric Naggum<p><a href="http://www.schnada.de/grapt/eriknaggum-xmlrant.html" rel="nofollow">http://www.schnada.de/grapt/eriknaggum-xmlrant.html</a>
I love the quote I originally saw on the Nokogiri (Ruby XML lib) site:<p>"XML is like violence – if it doesn’t solve your problems, you are not using enough of it."
The worst example of this that I deal with regularly has to be the libvirt domain XML.<p><a href="https://libvirt.org/formatdomain.html" rel="nofollow">https://libvirt.org/formatdomain.html</a><p>It does occasionally put information outside of the tags, but because there's no logic to when, it's nearly worse.
And JavaScript was never meant to be used to build applications...<p>There are many, many more inventions that are used for different purposes they were meant for.<p>The Internet was created so that US can withstand nuclear attack and it was never meant to be primarily used to spread advertisements.<p>Get over it.
I can't find much to corroborate this article's take. RDF is a stark counter-example - a standard from the W3C. It has endorsement from Tim Bray, one of XML's co-authors.