+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 :)

▲ NoboruWataya 2 days ago | parent | next [-]

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.

	▲	roenxi 2 days ago \| parent [-]
		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.

▲ bryanrasmussen 2 days ago | parent | prev | next [-]

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.

▲

ongy 2 days ago | parent [-]

EAD does indeed look like a good example of why we shouldn't use XML.

▲

bryanrasmussen 2 days ago | parent [-]

hah hah yeah, these scoped content examples would be a joy to do in JSON

https://www.loc.gov/ead/tglib1998/tlin125.html

▲

ongy 2 days ago | parent [-]

Yes. A sane schema that actually encapsulates the data would be a lot easier to read.

Earlier I had only seen the mix of values in body and values in tags. With one even being a tag called "value".

Thanks for showing more examples of XML being used to write unreadable messes.

▲

bryanrasmussen 2 days ago | parent [-]

you must find reading HTML a slog.

▲

ongy 2 days ago | parent [-]

I do. That's why I have a browser render it to a format that makes sense for human consumption.

Granted, html actually makes sense in the xml-ish (I don't remember if it's technically compliant), since it weaves formatting into semantically uninterrupted text.

If that's not the case, I don't see a real benefit to use XML over anything sane (not yaml... Binary formats depending on use case)

	▲	bryanrasmussen a day ago \| parent [-]
		>I do. That's why I have a browser render it to a format that makes sense for human consumption. I guess if that's the standard then reading any data format is also a slog because hey, most data and document formats get rendered as something for "human consumption" but that said when one is a programmer one often has to read the format without the rendering, and so, your witty reply aside I guess you must find this task where HTML is concerned a slog. This is too bad because most mixed content formats like EAD, HTML etc. are like that, and if you want humans to be able to write the content with say a paragraph, but inside that paragraph is a link etc. you're going to write it mixed content, because that works best based on millions of programmer and editor hours over decades and JSON would be crap for it. Is it super great, nope it's only the best way of writing document formats (with highly technical and mix of structured and unstructured content) that we currently know of, in the same way that Democracy is the worst form of politics except for all the all others and multiple other examples of things that suck in the world but are better than all the alternatives. I didn't say EAD was great, I said it was better than JSON for what it needed to do, part of which is having humans write mixed content. Believe me I have certainly seen people who have been JSON enthusiasts try to replicate mixed content type documents in JSON and it has always ended up looking at least as bad as any XML but without all the tooling to make it easier to write XML and with a tendency to brittleness because in doing mixed content in JSON you are going to have to do a lot of character escaping. I'm going to end off here with the observation that I doubt you are actually acquainted with the workflows of editors, writers, publishing industries and the use of markup formats in any sort of long running type of company using these things? I just have a feeling on this matter. You seem like your technical area of expertise is not in the area you are critiquing? Some of these companies are actually quite technically advanced, so I'm just putting that out there that you might not be as aware of the requirements of parts of the world that use things that you would build in a superior manner if only you were given the task to do so.

▲ bayindirh 2 days ago | parent | prev | next [-]

> 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.

▲ temporallobe 2 days ago | parent | prev | next [-]

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.

▲ weinzierl 2 days ago | parent | prev | next [-]

"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.

▲ ekianjo 2 days ago | parent | prev | next [-]

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.

	▲	AgentME a day ago \| parent [-]
		Uh can't XML have whitespace throughout it just as much as JSON? They seem pretty similar in this respect. `<foo bar="x" baz = "y" />`

▲ MrVandemar 2 days ago | parent | prev [-]

> 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.

	▲	bryanrasmussen 2 days ago \| parent [-]
		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.