<country name="Liechtenstein">
<rank>1</rank>
<year>2008</year>
<gdppc>141100</gdppc>
<neighbor name="Austria" direction="E"/>
<neighbor name="Switzerland" direction="W"/>
</country>
Why is the country name an attribute but not the rank? Why are all information about neighbors attributes but not children?Furthermore parsing JSON or YAML gives you an AST that consists of the basic data types like lists and dictionaries. Parsing XML gives you an AST that requires a lot more effort to turn into data in your domain. Even on the web, very few people like to use the verbose XML DOM API like childNodes, nodeType, getElementsByTagName et al; it is basically unheard of for anyone to use it outside the web such as in Python, despite that the DOM API is in the Python standard library since forever (see https://github.com/python/cpython/blob/3.14/Lib/xml/dom/mini... for example).
The problem, IMHO, was that rampant "xml-abuse" in the naughts. ws-* standards and over-engineered garbage like SOAP ("complex object access protocol") made people loathe XML.
I did like JAXB in Java, XLST, schemas, XPATH. Never got into XSL, but it seemed like good thing too. It worked best when your tooling manipulated it for you or at least helped you in an intelligent way. Much of the hate for XML came from situations where you had to deal with someone's over-the-top-one-size-fits all schema without the benefit of tooling to at least hint you in the right direction.
It still survives in WPF and c# *.proj files. If it were just me, I would still use it for object serialization. But json is king now even though it's inferior.
- element vs attribute ambiguity
- model of the document does not fit nicely to programming model of structs, dicts and arrays
- too many complexities (entities, cdata, parser directives)
- cardinality unknown without schema (is that a single value, or an array that just happens to have one element)
- order of elements may or may not be significant depending on schema
- not really extensible if the original schema does not explicitly allow for extensibility
- some types of valid XML documents are not representable by a schema (e.g. any number of different elements in any order)
- verbosity
- namespace identifiers being URIs that may or may not be resolvable
What I want for general data exchange is JSON with comments and sane namespaces.
Edit: line wraps
I am glad that younger generations are looking at it with fresh eyes. XML is a useful format; it has its place in your toolbox. Ignore the haters.
It's been a good choice for designing a new language, but we've been really surprised by the poor quality of the available parsers. We figured it would be a solved problem, but we'll be writing our own at some point.
Schemas, comments, transformation tooling, IDE integration,....
XML is a markup language, but most people that used it just needed a standard structured data format. In comes JSON which is more easily compatible with the object systems of various languages and in particular is compatible with Javascript syntax, and XML loses most of the people that used it.
As a markup language though, it seems pretty good. It's just that the amount of people that actually need an extensible markup language is much smaller.
I do hate the strictness of it. The header
<?xml version="1.0" encoding="UTF-8"?>
should be unnecessary. For a markup language, an already-made plain-text document should already count as XML. The tags should be something you can just sprinkle as you'd like to add contextual metadata.On XML I don't hate. I hate wrapping my head around XSLT but that is more about my head. AI may make XSLTing more bearable as it happens? I did work with someone passionate about XSLT. Aaaand now I am doxxed.
I also thing in practice schemaless i.e. JSON or "the schema is look at the code or some logs lol" won because fuck let's face it that is more fun.
json is just easier for my brain at this point if it needs to go over http, but ive seen some pretty... poorly designed json structures.
csv is always a good time. love when i can just plop important data into a table and query away
I write a lot of html already I don't need xml too in my life.
XML is verbose and therefore uglier than it ought to be. I think most of the haters hate it for that alone -- there's not much else to hate because you don't have to deal with the rest, it's not really imposed on you unless you really have to deal with someone else's XML application.
What do I mean? Well, the brackets thing and the necessity to repeat name of every element twice, in correct (LIFO, last in first out) order, isn't great, admittedly.
What XML has that the dev-bro alternatives that have flooded the void XML left since, haven't gotten and thus see being reinvented, are: namespaces, attributes and interop using the former two. Sure you can write JSON and YAML (the latter deservingly being incredibly hard to parse correctly -- they tried to design a better XML but failed IMO) -- but these suck as meta-languages because there's not much "meta" there. JSON, for example, allows you create properties and has a few types (kind of more than XML, really) but it leaves semantics up to you and namespaces are up to you to re-invent, poorly. If you think I am stretching the argument, see if you can represent an HTML document (no, not Markdown) with a JSON file.
YAML is a similar story, albeit with a few cool things like aliases. I think it's a better attempt to give the world a better XML, but the jury is still out on that one.
The killer thing with XML, for better and for worse, was plethora of tools to work with it. I wrote a fair share of XSLT documents to transform data, back when there was momentum in XHTML, for example. XSLT barely supports JSON and it's not pretty. XPath cannot natively understand YAML -- unless you convert it to XML which I guess re-animates XML as some sort of Frankenstein's monster. And even if it were a [pretty] monster, dealing with intermediate representation for the kind of purpose, is a can of worms all of its own.
Ironically nobody seems to hate HTML 5, seemingly. Or React basically turned it into a greasy cogwheel nobody needs to look at. Because if you look at it, it's in my opinion an abomination even compared to XML (unpopular opinion) -- the parser is quirky and behaviour is defined by the standard per element type (i.e. some elements need a closing tag and some do not, and what happens if you forget a closing tag is element-specific; care to remember the set of rules to ensure your document renders to your liking?). It has no namespaces but it has "custom elements" which require a dash in the name as poor' man's namespaces and you can't omit one, and now we have a Web of `x-spinner` and `x-carousel` because it turns out everyone rightfully wanted default namespace but didn't get one. Anyway, it's all plumbing, right -- the idea of _writing_ HTML has largely come and gone us by. And I am digressing.
So a return value that could have easily been two lined of text is now a nested demon of XML. The complexity isn't what that application does, the complexity is in how it returns the values.
Another good one is to use XML when something else would have made things simpler, e.g. for a config file where you could easily have used a .ini or a .toml file.
Or you have an application that tries to so generic that the definition for a simple use case is a whopping 5MB XML file. Cool. When I feel writing a config for your application is harder than programming the whole thing yourself you have really made it. /s