Comment by mattlondon
3 months ago
+1 I think XML "lost" some time ago. I really doubt anyone would chose to use it for anything new these days.
I think, from my experience at least, that we keep getting these "component reuse" things coming around "oh you can use Company X's schema to validate your XML!" "oh you can use Company X's custom web components in your web site!" etc etc yet it rarely if ever seems to be used. It very very rarely ever feels like components/schemas/etc can be reused outside of their intended original use cases, and if they can they are either so trivially simple it's hardly worth the effort, or they are so verbose and cumbersome and abstracted trying to be all things to all people then it is a real pain to work with. (And for the avoidance of doubt I don't mean things like tailwind et Al here)
I'm not sure who keeps dreaming these things up with this "component reuse" mentality but I assume they are in "enterprise" realms where looking busy and selling consulting is more important than delivering working software that just uses JSON :)
It may be that nobody would choose XML as the base for their new standard. But there are a ton of existing standards built around XML that are widely used and important today. RSS, GPX, XMPP, XBRL, XSLT, etc. These things aren't being replaced with JSON-based open standards. If they die, we will likely be left without any usable open standards in their respective niches.
Looking at the list, what actually jumps out at me is there is probably a gap in the world of standards for a JSON-based replacement to RSS. Looking it up someone came up with the idea of https://www.jsonfeed.org/ and hopefully it gains traction.
In hindsight, it is hard to imagine a JSON-based RSS-style standard struggling to catch. The first project every aspiring JS developer would be doing is how to add a feed to their website.
probably nobody would choose it for anything new because the sweet spots for XML usage have all already been taken, that said if someone was to say hey we need to redo some of these standards they can of course find ways to make JSON work for some standards that are XML nowadays, but for a lot of them JSON would be the absolute worst and if you were redoing them you would use XML to redo.
example formats that should not ever be JSON
TEI https://tei-c.org/ EAD https://www.loc.gov/ead/ docbook https://docbook.org/
are three obvious ones.
basically anything that needs to combine structured and unstructured data and switch between the two at different parts of your tree are probably better represented as XML.
EAD does indeed look like a good example of why we shouldn't use XML.
hah hah yeah, these scoped content examples would be a joy to do in JSON
https://www.loc.gov/ead/tglib1998/tlin125.html
4 replies →
> I really doubt anyone would chose to use it for anything new these days.
I use it to store complex 3D objects. It works surprisingly well.
XML might have “lost” but it’s still a format being used by many legacy and de novo projects. Transform libraries are also alive and well, some of them coming with hefty price tags.
"I really doubt anyone would chose to use it for anything new these days."
Funny how went from "use it for everything" (no matter how suitable) to "don't use it for anything new" in just under two decades.
To me XML as a configuration file format never made sense. As a data exchange format it has always been contrived.
For documents, together with XSLT (using the excellent XPath) and the well thought out schema language RelaxNG it still is hard to beat in my opinion.
LLMs produce much more consistent XML than JSON because JSON is a horrible language that can be formatted in 30 different ways with tons of useless spaces everywhere, making for terrible next token prediction.
Uh can't XML have whitespace throughout it just as much as JSON? They seem pretty similar in this respect.
> I really doubt anyone would chose to use it for anything new these days.
Use the correct tool for the job. If that tool is XML, then I use it instead of $ShinyThing.
I have a hilarious example of this. I was hired to consult at a large company that had "configurators" which were applications that decided all sorts of things for if you were building a new factory and needed to use this company's stuff for your factory, so for example one configurator would be a search for replacement part in your area - so if you are building a factory in Asia but you want to use a particular part but that part is has export restrictions for it from the U.S where it is manufactured you would use this tool to pick out the appropriate replacement part made somewhere in Asia.
They had like 50 different configurators built at different times using different tech etc. (my memory is a bit fuzzy here as to how many they had etc. but it was a lot) So of course they wanted to make a solution for putting their codebase together and also make it easy to make new configurators.
So they built a React application to take a configurator input format that would tell you how to build this application and what components to render and blah blah blah etc.
Cool. But the configurator format was in JSON so they needed to make an editor for their configurator format.
They didn't have a schema or anything like this they made up the format as they went along, and they designed the application as they went along by themselves, so application designed by programmers with all the wonder that description entails.
That application at the end was just a glorified tree editor that looked like crap and of course had all sorts of functionality behavior and design mixed in with its need to check constraints for outputting a particular JSON structure at a particular point. Also programmed in React.
There was about 10 programmers, including several consultants who had worked on this for over a year when I came along, and they were also shitting bricks because they had only managed to port over 3 configurators, and every time they ported a new one they needed to add in new functionality to the editor and the configurator compiler, and there was talk of redesigning the whole configurator editor cause it sucked to use.
Obviously the editor part should have been done in XML. Then people could have edited the XML by learning to use XML spy, they could have described their language in XML schema real easy, and so forth.
But no they built everything in React.
The crowning hilarity - this application at most would ever be used by about 20 people in the world and probably not more than 10 people at all.
I felt obligated by professional pride (and also by the fact that I could see no way could this project keep being funded indefinitely so it was to my benefit to make things work) to explain how XML would be a great improvement over this state of affairs but they wouldn't hear of it.
After about 3 months on it was announced the project would be shut down in the next year. All that work wasted on an editor that could probably have been done by one expert in a month's time.