Well, allow me to clarify my perspective on that topic. I'm using XML extensively in my day-to-day life. And I think it is a clever syntax to present data. Maybe a little bit overloaded with meta information, but clever anyway. It has it's own weaknesses, but in general it is a good data format to use. It is a standard, its backed by a lot of tools and it is ubiquitous throughout the computing world - supported by most of modern languages, frameworks and libraries.
My attitude toward XML was changing all the time I was using it. First it was confusion from that mystic way to organize data - it was hard to understand the concept of semantic mark-up since years of HTML formatting. But when the idea became dominant I started to appreciate the power of XML and tried to use it everywhere I can - transfer protocols, data formats, configurations... It soon became apparent that I'm actually writing real programming languages in XML. And a lot of people, including framework developers, doing that too. So we ended up in the world where we are doing more declarative coding in XML than coding in imperative programming languages... And some ideas are taking much more space to express in XML, so it does not make things concise.
Once I realized that, I switched from blind injection of XML into anything I could to a more pragmatic approach. I think we are overusing XML a lot these days. And it fits well for some purposes, but for others makes things more complex. By trying to fit XML where it doesn't belong we are loosing a sense of simple solutions and getting the XML overdose.
And that XML overdose playing tricks with our brains - just look at the Maven dependency declaration:
<dependencies>
<dependency>
<groupid>junit</groupid>
<artifactid>junit</artifactid>
<version>4.0</version>
<type>jar</type>
<optional>true</optional>
</dependency>
</dependencies>
In this case Maven is blindly following best recommendations you can find at W3C Schools. They suggest to use elements instead of attributes, since elements are flexible, extendible, can have multiple values etc... When do they propose to use attributes? Well, when you have some identification values like NAME or ID.
So, you can look at it this way - groupid, artifactid and version are like identifiers for a dependency. So you can put them as attributes. Developers of Apache Ivy have done just that. And the same declaration in Ivy would take only one XML string:
<dependencies>
<dependency org="junit" name="junit" rev="4.0" optional="true"/></dependencies>
We can get rid of XML at all. And Gradle by doing that makes the declaration even more concise:
dependencies {
testCompile 'junit:junit:4.0'
}
Now that is a big needle to stick into anyone affected by the XML overdose!
Just ask yourself - why do I need bloated syntax to define my project dependencies? Only because it is a STANDARD and it is a way most developers doing it?
I'd better keep my own perspective on this matter since I'm tired of tag-bloat in my pom.xml files.
If you are designing an XML format humans are going to work with, try to keep it as simple as possible. That is the only ground rule here. Avoid unnecessary structures and nesting, try to minimize mandatory values by using defaults. And most of all - DO NOT use XML namespaces - they are making tags ugly and unreadable. If it is possible, consider using some alternative format instead of XML.
In summary, with some effort on our part, it is possible to make XML data confortable to work with. Just do not overdose it!
P.S. Don't get the impression I have something against monochrome terminals. I'm a fan of retro-computing. Maybe I missed the glory days of PDP-11 era, but I had my time programming ZX Spectrum in early 90s. And it was a great time with a really neat machine!
