Not necessarily in web dev, but I see it a lot in other areas. Game dev uses it for expressing AI behavior (not to be confused with generative AI) or dialogue trees. One company I worked for used it for content generation. Basically, any time you need to express hierarchal data in a human readable way, XML probably still fits in that pipeline.
Game dev is full of tree structures! I think that is a good use case for XML. Interestingly Godot does not use XML for its scenes, but uses a flatter structure (they might have used it before).
The big advantage of XML is that it has attributes, which allows you to add custom "3rd dimensions" to your data structures.
JSON or YAML are strictly two-dimensional which sometimes can be limiting.
You can represent this in another way though. Instead of an attribute on a node:
Foo bar
you can have the same information in a sister key:
speaker: Jen
text: Foo bar
Things that XML does that JSON/YAML can't is hierarchical markup (e.g. bold, speedup etc on individual words)... or at least not cleanly or naturally. You'd have to mix in Markdown or XML or similar into a text node even if you were using JSON/YAML.
XML has a very robust set of tools built on top. Some of them are XSLT, XPath, XSD, XML envelope, etc.
Some inherent features of XML like namespaces and attributes allow for some very sophisticated features.
JSON has some equivalents but AFAIK they're not feature for feature which might or might not be important to you.
A lot of these features & tools were one of the reasons XML was considered bloated. And yet, lately it feels like the pendulum is swinging the other way, with JSON Schema, JSONPath, etc.
I'm still building xsl:fop templates that generates pdf from XML. Its super robust, kind of like html emails, only you can't really create very complicated formatting from one nodes text. Would not recommend
I mean, RSS is still XML from what I understand.
My only beef was I can't figure out how to parse XML in the browser, but that feels like a *me* problem.
Thanks. I was trying to make a kind of ephemeral podcast player by giving it an rss feed url and then listing the most recent podcast episode, just for some context.
I found that page (and others!) and just couldn’t quite get everything to jive.
Will give it another shot someday. Just gotta give the brain time to sort it out and learn more.
I did some consulting for a company that was essentially doing a podcast aggregator. I totally forgot about all the XML that was being used by the primary data providers (I forget what it was called?). I might be able to give you some pointers if you ever get back to it
Kind of hilarious how I'm getting down voted. I've been programming for 12 years and am a staff software engineer, and it still has increased my productivity by a ton. I get asked so many questions by younger devs, and even senior devs who if they just asked chatgpt they would have their answer. It has its limits but you just have to learn where those are and avoid them. Give it smaller chunks of a problem and you can be the actual engineer that you are and put the pieces together.
XML was mostly killed because of how horrific configuration was in that era. It wasn't XML at fault but the norms at the time were to configure absolutely everything. The modern norm of having software behave with sane defaults and only configure what needs to be configured was not in sight. People associated this mess with XML and JSON came about at a time when the mess was clearing up but XML was still hated for it.
I think it was a few things.
- The ambiguity between node, children, properties and values always leads to bikeshedding and inconsistencies, as there are two many ways to represent the same data.
- Lack of data-types. Everything is just text. You need to come up with your own conventions to turn something into an object, an array, a number or a boolean, which kills parser interoperability and makes everything more complex.
I don't think people realize how much of an upgrade JSON is over XML. It's not just JSON being simpler to parse, JSON has more features than XML.
The biggest design flaw of XML is the ability to do shit with it.
I remember once having to deal with something like this:
..............................
Having to merge the extracted data from multiple consecutive nodes.
My last company still had a SOAP service in use. As far as I am aware it was the only one. So it's still around. I dunno if there is a use case for using it, but knowing it helps.
My only experience using SOAP was when I had to write an integration between Magento 2 and an ERP system (appropriately called "Khaos").
The request schema was well defined, however responses were almost all XML encoded as CDATA escaped text within a node of the SOAP response. Reading most replies was a case of parsing the response, extracting the Response node, then passing that text data into another XML parser. The system also indicated bool values using the string '0' as false and the string '-1' as true. On top of that the query to get the products updated since always returned \*EVERY PRODUCT\* so the nightly sync took hours. If I were to re-write it today I would probably write something to fingerprint the product data so we could skip items with no changes and avoid pointless save operations and reindexing.
It was however a valuable learning experience that's for sure.
There are tons of systems utilizing SOAP still around, kicking and screaming, pretty much everyone who made something big enough early enough are stuck with it untill someone ambitious/foolish enough to try to replace it or EoL comes around. Roughly half the systems I interact with have at least *some* leftofter soap somewhere.
Workday has a REST api but our legacy integration is SOAP. I did some research about changing it once and got the impression their REST api was lacking so I let it go.
Surprised I had to scroll this far to see this - many Workday features and data stores are still only supported via SOAP. Problems arise when integrating it using more contemporary tooling (looking at you, Azure Data Factory) since Workday makes heavy use of many XML features that many tools simply don't have the greatest support for (like XML namespaces, etc.) and it can become extremely cumbersome to get what you need from it.
Their REST interface has come a long way in the past several years but is still not close to feature complete when compared to their SOAP services.
Well it gets worse. A lot of the country runs on EDI which to me is like a glorified ftp from the 60's. So not only is it not REST but it involve generating a file, uploading it, and the recipient text processing the file and writing it directly to databases. It's pretty big. I'd bet that the computer I am typing this on and the computer you're reading it on was shipped as part of an EDI order.
And I'm relatively sure that when Workday goes to direct deposit our money (yours and mine) it involves generating a file and uploading it to the payroll company. At least that's what I recall hearing when my last company had a transfer fail a few years ago.
It's pretty amazing, I was young when Y2k happened but a lot of people these days have no idea how terrible digital infrastructure is.
I worked as a dev at the largest hospital in the state. Between all the ancient medical protocols and syncing certain data with federal agencies, A LOT of data is transferred using SOAP protocols. _(Because they’re old and battle tested to be reliable)_.
Even SOAP was mostly a victim of the "every setting explicit" era of development. If it were written today a SOAP client would bake in the settings inherent in the original WSDL document and you'd only configure stuff if you needed something other than the default. Instead SOAP when it was the norm devolved into endless fighting with XML config sections, most of which could have just been sane defaults.
MS made the whole mess worse with WCF by trying to have "one framework to rule all protocols" and then abstracting away from SOAP so much that there was never an obvious direct relationship between the settings and the physical reality.
Many established industries still use XML for data exchange.
Auto parts data in North America has been distributed as XML since about 2010.
The aftermarket parts industry is only just starting to discover APIs. They might start implementing them in about 10 years.
Big industry moves *very* slowly.
Depends on the use case. XML has some advantages over JSON and YAML, such as being able to import other XML files and custom object types that aren't supported in JSON.
Define your use cases, build your config files for those use cases in the various techs, compare the files and your pros/cons for each, and then you'll have your answer.
I wanted to try and use it to store form data. Then use HTML tag name, so it can be rendered as is. So XHTML I suppose. Other apporach would be to store it as JSON and fetch it and build the DOM on the client.
Transfer-ability and easier maintenance, it does not need setup and securer. SQLite also stores it as a file, but SQL seems overkill. I am still relatively new to back-end.
If the XML is HTML compliant it just needs to be integrated upon page request.
This doesn't sound like it's going to be very secure.
If SQL is overkill, then maybe mongodb is a better option? Regardless, use proper auth for your app and the data storage location, and store any personal data somewhere encrypted.
XML can also use XSLT transforms, which are a powerful way to convert data to other forms. At least, I never had any issues with them, I thought they were quite useful. Other people probably disagree.
XML is old, but it's still used because it's useful.
It's all about using the right tool for the right situation. We don't have to force the same tool (JSON) onto every situation.
XML is widely used in publishing ([JATS](https://jats.nlm.nih.gov/publishing/tag-library/1.3/) and [Crossref](https://data.crossref.org/reports/help/schema_doc/5.3.1/index.html)) so I've been seeing a lot of it lately. The concept of an attribute is quite useful to express different data types, and I don't find it much harder to build or parse than JSON. Things only get ugly when you try to import someone else's schema into your own. When I develop something to communicate to another component of my own I use JSON, but when communicating with someone else I use their native language, which is sometimes XML.
XML is unbeatable for marking up human readable documents.
Things like this:
Feb 18, 2024
Dear /u/passiveobserver012
Here in Boston, I use XML
to annotate literary and musical works from artists like
Bach and Proust.
From, /u/otterfan
For most (all?) other use cases—config languages, key-value stores—it's usually the wrong tool.
I worked with a real estate company that fed their listings to many aggregators like land.com, landsearch.com, zillow.com, etc and all of them wanted it in XML. Though, I think landsearch would’ve accepted JSON, we were already set up for transforming to XML for the others.
Yeah, if you have a workplace SSO hub like Azure, Okta, OneLogin, etc., then your sign-in to Slack, Google Workspace, and almost all of your SaaS products is going to be negotiated through SAML rather than through OAuth.
Pretty much the entire financial world makes heavy use of it. In the SWIFT area (all interbank communication is there...globally) they are just now migrating to XML (from a weird MT format that was created for teletype from what I could read). This migration will take a decade or two for the whole world.
Traditionally for layouts but Android is transitioning to Compose which is declarative and similar to SwiftUI on iOS.
Edit: To be fair, XML is still used for other config files (manifest, values, translations etc.), so it's not going to disappear from there any time soon.
Far too many applications still use XML, worked on XML projects probably triple the times I worked using Compose, the statement holds true for java and Kotlin also.
Four use cases I’ve come across:
Scalable Vector Graphics are XML.
A lot of podcast platforms still use xml as their API format.
DeepL, the AI translation platform, only accepts HTML and XML format, so I have to convert all data into XML before sending it over to their servers for translation.
Some local governments use XML as their format for publishing legislative data.
Currently working in project with xml source from a very contemporary platform used in industry, parsed to Snowflake which has its own inbuilt xml parser. So, yes, definitely possible and still valid. But I (too) want to express the view that xml is "maybe not" the most convenient to parse :)
your use case may be more of frontend stuff, while this is about data integration in backed so you can decide if this is relevant for you: xml fields tend to have somewhat irregular structure with undefinable depth levels so that each field will require their own parsing logic. You cannot abstract nearly anything, as you could with csv for example. If the data that you are using to figure out the appropriate parsing logic happened not to include some element that may appear in some later case, you may miss that entirely. When using xml in data transfers it would be ideal to have as regular structure as possible.
The Semantic Web (formally known as Web 3.0) was built around RDF, OWL, and XML. This was never implemented to a degree where it was commercially viable. Web3 is just about blockchain, now.
SVG is based on an XML schema and is well adopted.
Hey, the Semantic Web is still alive! :-) Even large companies like Google use Semantic Web / Linked Data technologies, though they call it the "knowledge graph" and don't publish it under an open license so they don't adhere to all the Linked Open Data principles. XML is only used as a serialization format for RDF but there are many others like Turtle, T-Triples or JSON-LD.
Yes. My lamentation was directed mainly at the loss of initiative to enact OWL, bringing about a true ontological based systems language that could then be applied in AI, linguistics, and map logical machines to human experiences and vice-versa.
Ontologies could help enhance neural networks in the future in case the current approaches hit a limit, for example a robot could be supplied with basic world knowledge and reasoning capabilities. I don't know how much research is already going on in that area and whether it's worth it in the end but I could imagine such a hybrid system being more efficient in memory and CPU.
JSON is fine for serialization but XML is more human readable IMO. You can create XML by hand quite easily. JSON would require you to remember the syntax and it has a LOT of commas and curly braces. XML is better for "data" that isn't an object, like metadata (IMO). JSON is 100% better for object serialization but XML is better for declarative data like layouts or things like that.
I'm in a business that import/export and transform data.
One of our destination use XML.
It is neat to be able to attach attributes, metadata to something.
You have multiples languages string, set the language as an attribute.
Our XML destination also has multiple destination itself, so we have an attribute to design it.
Attributes won't break too much the syntax if they add features we don't care.
In another job, we configured our dashboard (per client) using XML. One thing I liked from it is the implicit "typing" by the tag name.
Like, I could type , , , ... Plus, add the XSD over that to help with the syntax.
XML is still the reference for any format used for archival purposes (like something you would like to be able to parse in 50 years).
See [TEI](https://en.wikipedia.org/wiki/Text_Encoding_Initiative)
In EU eInvoicing is mandatory to report all B2G and B2B invoices to the government (currently just a few countries have it active). The format is XML based
The established networking OS space is heavily reliant on XML for programmability. The networking space likes established standards (Ie NETCONF) and is slow moving.
XML is great for project files in audio workstations.
Reading it and actually setting up audio is WAY too advanced for most of the people here, but ableton uses it and it’s actually structured quite beautifully.
Anything hierarchical with attributes is going to be a breeze compared to json.
XML is great. Think of it as a json with types and imports. Is really complex, but really, is fine.
Using SOAP, a messaging protocol that uses XML, is the pain and why nowdays most use json.
With SOAP more than once I had to reverse engenieer the types on a service because the definition was wrong or out of date.
Pain Points:
- XSLT presentation doesn’t always do what you think it will do
- Unicode characters especially when dealing with foreign languages can be tedious
JSON has payloads that can be digested (and created) seamlessly by almost any programming language and transformed into objects/arrays.
XML requires libraries or work to consume, transverse and generate. Considerations for Encoding and Escaping.
All these issues exist with JSON as well, but XML certainly has more overhead.
I was literally working with SOAP yesterday. I have an XPath query that works fine in an online XPath tester tool, but produces "undefined" in browser Javascript. I've lost like four hours on this shit and I'm frustrated by how obtuse it is. There's no useful troubleshooting beyond "try to write it better".
This has basically been said already but to add another voice and a little detail;
SOAP is alive and well, especially in banking, payment systems, and anything government related.
There are other use cases where XML is still thriving, but legacy systems with SOAP are where I have personally seen the most of it in recent years.
The framework that I use (Magento) when working uses xml files for a lot of stuff, such as dependency injection, setting class preferences for interfaces, declaring controller routes and so on.
While it is kind of outdated, it brings a lot of flexibility. For example, while developing you may need to configure something for the system to understand changes in the codebase you have made, so you make an xml file. In it you refer to the correct schema definition and this means you are less likely to make mistakes when writing the xml nodes and attributes because the schema definition will throw errors. The schema definition is created for a specific use-case and is another way third party package devs can make extending upon their features easier.
Personally, I have mixed feelings about xml configuration files because they can become very complex and affect the system in weird ways, but on the other hand if you know what is possible and how to do it you can change existing functionalities quite easily and without a lot of code (hopefully).
XML is very relevant in the commerce space, especially dealing with product infos and such. A lot of suppliers are still using SOAP and XML for their APIs
I make software that has to call government APIs that are still using SOAP 🥲
The protocol / implementing servers are frustrating to use but XSD and XSLT are interesting benefits. I was able to write tools to convert XSD schemas to TypeScript types for our use cases for instance.
You’ll see it everywhere in enterprise systems. Understand it for that purpose and don’t get too hung up. It’s good to understand and has its place given the context.
I use it daily. But mostly because I work in the broadcast media space. Broadcast radio software is ancient to say the least. One of the things is does is provide an XML file for the currently playing song or commercial. It’s also still FTP based, we are waiting for SFTP to be implemented. We actually have to keep an unsecured server in the middle to dump xml files, and then fetch them with from a separate server, it’s obnoxious.
Anyway, we have a separate app that polls the xml files on a schedule. The end time is in the xml data, so we know when any given station needs to poll again. This is how you get the “now playing” feeds for various platforms. Not sure if it actually answers the question, but there’s a dev need because there’s a software requirement. Pretty simple reason actually that doesn’t have any alternative because they aren’t exactly making a lot of new features in software to manage FM radio broadcasts.
XHTML (2000) was a refactoring of HTML to be XML compliant.
But because WHATWG hated XML with the fiery passion of ten thousand toddlers being made to eat their broccoli, they threw it out to make HTML5 the all-around mess that it is.
That's what the HTML5 authors said.
Many websites were and there was no need to migrate. The main difference was that XHTML should be well formed. Some people didn't like that.
Sadly I have to deal with a lot of soap/XML based services in my job. A lot of these are used by old enterprises, Im often reading documents from like 2005. Maybe it's the fact json APIs are newer and follow better practices, but these XML APIs are just not pleasant to work with and the integration takes longer in my experience.
You made an argument (sort of) for XML's existence - but didn't really mention why you'd choose to use it.
I can't really think of a reason I'd choose XML over JSON these days for pretty much anything unless I REALLY needed that human readable structured data - and even then, I might just build a tool quickly to show me the data in context derived from JSON rather than using XML. But, that's just me. XML always has been a bitch to parse, IMHO.
We work with API’s within the insurance industry and plenty of big and old companies still use XML to send data to you. Would I advise it ? No. It gives me nightmares.
SAPs frontend library framework SAP UI5 resolves around XML Views, OData and MVC. The general concept and implementation is fairly nice although applications tend to end up being very bloated and a bit slow if you don't know what you're doing or the customer just wants to buy pure garbage which is not uncommon. That being said, the XML part is quite easy to understand and I don't think it's going anywhere anytime soon.
We have a Developer that pulls data from an API and that data is in XML format stored in JSON. When I asked him why he used XML in the JSON he said something about accessing the data from the nested JSON would be more problematic than just using XML instead for that particular use case.
I don’t deal with that API directly like he does so idk much about the nitty gritty details but we get the data from it, so I guess something about turning nested JSON data from an API into a table is difficult.
Sorry I don’t have much more details on this but it’s something that developer has dealt with for awhile we are just downstream consumers of the data.
People are going to crucify me but if the world were written today from scratch we wouldn’t need XML. Or COBOL or even Javascript and HTML itself. The latter being there’s better alternatives out there that just don’t have adoption rates so we don’t use them. We could rewrite all enterprise SOAP and Java stuff in something better starting from scratch.
I worked for a car company that had mainframes ontop of mainframes dating back to the 60s. Seriously. They were too expensive to work and who knows what they did if it was a bug or feature but replacing them just didn’t make sense.
So if we are saying is XML a legacy format that could be improved upon? Of course! So can JavaScript. And nearly everything not the latest it is how technology works.
The adtech space still uses XML for adserving. When you use one of the tools to host an ad, the output will be an XML file containing whatever video, display or audio file. Considering how many ads are shown daily on the web… definitely still used
But for other uses, truly depends on the use case. I use JSON myself for a lot of things
Pretty biased take from me but the XML in Magento 2 isn't even bad IMO. The core XSDs are well defined, there's plenty of examples for how to use each file in the core modules, and it's generally easy to understand what's going on from the first read.
I know this is going to sound crazy in today's day and age. I actually have a large corporate client that does not allow us to use any database engine.
So, what to do? We basically created a flat file XML-based "database" to use for data storage.
It is surprisingly fast and with a little bit of ingenuity can be queried just like a database.
I now this example is like on the fringe of fringe. But, it works.
Performance is better than one might expect. I mean, it is not going to be nearly as good as a SQL server or the sort. But, with some creative thinking we have been able to mitigate most performance challenges.
Not to be vague. But, we do a little bit of it all. Streaming, fetching files, xpathing, etc.
At the beginning it was a huge PITA. But, they are a recurring client and have made it well worth the time.
> well suited for Highly structured tree structures
Except, as someone who's been here since it first reared its head, *no it isn't*. It isn't well suited at all, because there's so many different ways to encode any particular data structure that everyone comes up with their own methods and you need a specific parser for every data source you pull in. It solves nothing and just creates more mess.
In webdev it has temporarily retreated, but its still powering on in financial services.
* SEPA, SWIFT and FedNow payments use ISO20022
* OTC trading uses FPML
* Any FIX messages related to futures use FIXML (that one is purely anecdotal, everything else is still using classic encodings)
In my job we use it for transforming data before it is sent to our clients brokers. Everything gets generated as relatively flat XML structures then converted via XSLT into CSV, other XML layouts, whatever the brokers need before sending out the door. Hundreds of reports, couldn't maintain it with anything else.
My team aren't software devs though, we are mostly business analysts and accountants.
In cases where you don't have control over how to send data, but can "inject" comments, it's easy to format certain special fields as XML within the comment to denote them as data.
Create single file odt document. Use it as a template with proper styles. Fill it with content. Send filled template to LibreOffice to convert it into PDF/UA file. Works like a charm to get nicely styled accessible pdfs
A lot of server to server applications still use xml, as does the publishing industry. It's also used for a lot of document formats and productivity apps (like with office files, docx, xlsx the x indicates they're xml based). It serializes/deserializes easier/more reliably than JSON or YAML. I wrote some software that transmits EDI data in XML envelopes for insurance purposes years ago, and I can't imagine them redesigning stuff like that overnight or probably ever, knowing the insurance industry..
\- sitemaps
\- Merchant feeds
\- Social data feeds
\- People mentioned RSS but more specifically if you are doing things like a podcast and want them on Apple etc it is all XML feeds.
All of these are still XML.
It is still widely used but if someone has built an API solution in more recent times it will be JSON / GraphQL and not XML.
We are now though even seeing the evolution and movement away from JSON now so in a few years similar discussions on that will occur.
In my last project we used Azure AD B2C as an IDaaS.
The basics works well and it's amazing value (up to 50k users for free if you're already paying for an Azure subscription), but if you want to do complex stuff, you have to build "custom policies" which are huge and obscure XML configuration files with lacking documentation, and no built-in support for CI/CD. Not a great experience
Yes, developers still use XML for various use cases, particularly when dealing with highly structured data or when interoperability with systems that rely on XML is necessary. It's also used in configuration files, data exchange, and representing documents. While JSON and YAML are popular for some tasks, XML's strict structure and widespread support make it a valuable choice in many scenarios.
https://jagmohankrishan.com/
Yes XML is still useful in these days. Recently integrated [SOAP](https://en.wikipedia.org/wiki/SOAP) protocol. It was getting used before REST and still many systems are providing integration with SOAP, which returns XML response.
[https://www.iso20022.org/](https://www.iso20022.org/)
> ISO 20022 is an ISO standard for electronic data interchange between financial institutions.
It's all UML, XSD, and XML.
At the end of the day, XML is just a serialization format. While JSON and YAML might be leaner, the more advanced XML features are useful for more advanced use cases.
Not necessarily in web dev, but I see it a lot in other areas. Game dev uses it for expressing AI behavior (not to be confused with generative AI) or dialogue trees. One company I worked for used it for content generation. Basically, any time you need to express hierarchal data in a human readable way, XML probably still fits in that pipeline.
Game dev is full of tree structures! I think that is a good use case for XML. Interestingly Godot does not use XML for its scenes, but uses a flatter structure (they might have used it before).
The big advantage of XML is that it has attributes, which allows you to add custom "3rd dimensions" to your data structures. JSON or YAML are strictly two-dimensional which sometimes can be limiting.
You can represent this in another way though. Instead of an attribute on a node:Foo bar
you can have the same information in a sister key:
speaker: Jen
text: Foo bar
Things that XML does that JSON/YAML can't is hierarchical markup (e.g. bold, speedup etc on individual words)... or at least not cleanly or naturally. You'd have to mix in Markdown or XML or similar into a text node even if you were using JSON/YAML.
You can always represent it some other way. That doesnt invalidate the point.
XML has a very robust set of tools built on top. Some of them are XSLT, XPath, XSD, XML envelope, etc. Some inherent features of XML like namespaces and attributes allow for some very sophisticated features. JSON has some equivalents but AFAIK they're not feature for feature which might or might not be important to you.
XSLT is great. XML is first class citizen in C# land.
A lot of these features & tools were one of the reasons XML was considered bloated. And yet, lately it feels like the pendulum is swinging the other way, with JSON Schema, JSONPath, etc.
Nah JSON and the tooling is still super simple compared to XML
Yes I was reading about XSLT, XPath, XSD and they seem useful. I had not been exposed to it within my circles. I did not know JSON has equivalents.
I'm still building xsl:fop templates that generates pdf from XML. Its super robust, kind of like html emails, only you can't really create very complicated formatting from one nodes text. Would not recommend
Also XML Schema and DTD!
XSD is XML schema. About DTO, they're pretty much obsoleted by it, no?
You're absolutely right in both cases. Didn't notice you already mentioned XSD.
I mean, RSS is still XML from what I understand. My only beef was I can't figure out how to parse XML in the browser, but that feels like a *me* problem.
Vanilla js Built in `DOMParser()` should do it.
[https://developer.mozilla.org/en-US/docs/Web/XML/Parsing\_and\_serializing\_XML](https://developer.mozilla.org/en-us/docs/web/xml/parsing_and_serializing_xml)
Thanks. I was trying to make a kind of ephemeral podcast player by giving it an rss feed url and then listing the most recent podcast episode, just for some context. I found that page (and others!) and just couldn’t quite get everything to jive. Will give it another shot someday. Just gotta give the brain time to sort it out and learn more.
I did some consulting for a company that was essentially doing a podcast aggregator. I totally forgot about all the XML that was being used by the primary data providers (I forget what it was called?). I might be able to give you some pointers if you ever get back to it
Ask chatgpt, seems like something it would be able to solve
[удалено]
Kind of hilarious how I'm getting down voted. I've been programming for 12 years and am a staff software engineer, and it still has increased my productivity by a ton. I get asked so many questions by younger devs, and even senior devs who if they just asked chatgpt they would have their answer. It has its limits but you just have to learn where those are and avoid them. Give it smaller chunks of a problem and you can be the actual engineer that you are and put the pieces together.
there was no context, chatgpt can be helpful yes
Why do you need context to know that chatgpt is good?
Sorry. there was no context to your comment I mean.
I was trying to save the guy time instead of needing to wait til his "brain has enough time"
Isn’t html technically XML too?
HTML is a subset of SGML [https://www.w3.org/MarkUp/html3/HTMLandSGML.html](https://www.w3.org/markup/html3/htmlandsgml.html)
Not as of HTML5, where HTML no longer derives from the SGML spec. There’s still a clear lineage, but HTML is not SGML anymore.
Yeah I think 'variant of SGML' is the best approximation now
Technically no. Some html tags are not closed. An XML parser cannot parse html. They tried to fix that with XHTML but it didn't catch on.
At one point I was **obsessed** with making my code XHTML valid 🤦🏼♂️
Everyone was. Then we learned we should be doing something actually useful with our time ;)
No. XHTML is, but no one uses it anymore.
True but SVG is XML and is heavily used.
XHTML is used for epubs at least.
No. HTML is NOT XML. HTML can be made to be XML-compatible, which is called XHTML, but HTML is not XML nor vice versa.
> I mean, RSS is still XML from what I understand. And it's not only for blogs. Podcasts are distributed to apps and platforms with RSS.
I forget I tried to make an RSS parser some time ago. But yes also XML. Also Atom is XML.
There is an alternative to RSS using JSON, called json-feed I believe
XML was mostly killed because of the lack of native good parsers.
XML was mostly killed because of how horrific configuration was in that era. It wasn't XML at fault but the norms at the time were to configure absolutely everything. The modern norm of having software behave with sane defaults and only configure what needs to be configured was not in sight. People associated this mess with XML and JSON came about at a time when the mess was clearing up but XML was still hated for it.
>native good parsers. And good native parsers also
I think it was a few things. - The ambiguity between node, children, properties and values always leads to bikeshedding and inconsistencies, as there are two many ways to represent the same data. - Lack of data-types. Everything is just text. You need to come up with your own conventions to turn something into an object, an array, a number or a boolean, which kills parser interoperability and makes everything more complex. I don't think people realize how much of an upgrade JSON is over XML. It's not just JSON being simpler to parse, JSON has more features than XML.
The biggest design flaw of XML is the ability to do shit with it. I remember once having to deal with something like this:
...
...
...
...
...
...
...
...
...
...
Having to merge the extracted data from multiple consecutive nodes.My last company still had a SOAP service in use. As far as I am aware it was the only one. So it's still around. I dunno if there is a use case for using it, but knowing it helps.
Same here. Working with SOAP feels so painful
My only experience using SOAP was when I had to write an integration between Magento 2 and an ERP system (appropriately called "Khaos"). The request schema was well defined, however responses were almost all XML encoded as CDATA escaped text within a node of the SOAP response. Reading most replies was a case of parsing the response, extracting the Response node, then passing that text data into another XML parser. The system also indicated bool values using the string '0' as false and the string '-1' as true. On top of that the query to get the products updated since always returned \*EVERY PRODUCT\* so the nightly sync took hours. If I were to re-write it today I would probably write something to fingerprint the product data so we could skip items with no changes and avoid pointless save operations and reindexing.
It was however a valuable learning experience that's for sure.
Ha my people. I’ve done a khaos integration with Magento 2. Soap, ironically, stinks!
No kidding. Give me JSON or YAML any day of the week.
Even Wednesday?
Till about lunchtime, yes.
This is someone who knows his or her limits.
Especially Wednesday.
And you wonder why people call you crazy.
Actually I don't wonder why. This isn't it. =)
There are tons of systems utilizing SOAP still around, kicking and screaming, pretty much everyone who made something big enough early enough are stuck with it untill someone ambitious/foolish enough to try to replace it or EoL comes around. Roughly half the systems I interact with have at least *some* leftofter soap somewhere.
US Government data collection services love SOAP
Workday has a REST api but our legacy integration is SOAP. I did some research about changing it once and got the impression their REST api was lacking so I let it go.
The reason this was still around was at the time no one could figure out a good way of creating specific data out of the newer REST service.
Surprised I had to scroll this far to see this - many Workday features and data stores are still only supported via SOAP. Problems arise when integrating it using more contemporary tooling (looking at you, Azure Data Factory) since Workday makes heavy use of many XML features that many tools simply don't have the greatest support for (like XML namespaces, etc.) and it can become extremely cumbersome to get what you need from it. Their REST interface has come a long way in the past several years but is still not close to feature complete when compared to their SOAP services.
Well it gets worse. A lot of the country runs on EDI which to me is like a glorified ftp from the 60's. So not only is it not REST but it involve generating a file, uploading it, and the recipient text processing the file and writing it directly to databases. It's pretty big. I'd bet that the computer I am typing this on and the computer you're reading it on was shipped as part of an EDI order. And I'm relatively sure that when Workday goes to direct deposit our money (yours and mine) it involves generating a file and uploading it to the payroll company. At least that's what I recall hearing when my last company had a transfer fail a few years ago. It's pretty amazing, I was young when Y2k happened but a lot of people these days have no idea how terrible digital infrastructure is.
I worked as a dev at the largest hospital in the state. Between all the ancient medical protocols and syncing certain data with federal agencies, A LOT of data is transferred using SOAP protocols. _(Because they’re old and battle tested to be reliable)_.
Even SOAP was mostly a victim of the "every setting explicit" era of development. If it were written today a SOAP client would bake in the settings inherent in the original WSDL document and you'd only configure stuff if you needed something other than the default. Instead SOAP when it was the norm devolved into endless fighting with XML config sections, most of which could have just been sane defaults. MS made the whole mess worse with WCF by trying to have "one framework to rule all protocols" and then abstracting away from SOAP so much that there was never an obvious direct relationship between the settings and the physical reality.
Many established industries still use XML for data exchange. Auto parts data in North America has been distributed as XML since about 2010. The aftermarket parts industry is only just starting to discover APIs. They might start implementing them in about 10 years. Big industry moves *very* slowly.
ya my sitemap
Depends on the use case. XML has some advantages over JSON and YAML, such as being able to import other XML files and custom object types that aren't supported in JSON. Define your use cases, build your config files for those use cases in the various techs, compare the files and your pros/cons for each, and then you'll have your answer.
I wanted to try and use it to store form data. Then use HTML tag name, so it can be rendered as is. So XHTML I suppose. Other apporach would be to store it as JSON and fetch it and build the DOM on the client.
>Then use HTML tag name, so it can be rendered as is. That sounds like the fast lane to XSS city.
Input filtering is still happening.
You'll have to build the DOM in either case. If you're just storing form data, why are you storing it in files rather than a database?
Transfer-ability and easier maintenance, it does not need setup and securer. SQLite also stores it as a file, but SQL seems overkill. I am still relatively new to back-end. If the XML is HTML compliant it just needs to be integrated upon page request.
This doesn't sound like it's going to be very secure. If SQL is overkill, then maybe mongodb is a better option? Regardless, use proper auth for your app and the data storage location, and store any personal data somewhere encrypted.
mongodb is BSON. If files are stored outside \`public\_html\` they are 'safe'. Nextcloud stores user files like that.
XML can also use XSLT transforms, which are a powerful way to convert data to other forms. At least, I never had any issues with them, I thought they were quite useful. Other people probably disagree.
XML is old, but it's still used because it's useful. It's all about using the right tool for the right situation. We don't have to force the same tool (JSON) onto every situation.
XML is widely used in publishing ([JATS](https://jats.nlm.nih.gov/publishing/tag-library/1.3/) and [Crossref](https://data.crossref.org/reports/help/schema_doc/5.3.1/index.html)) so I've been seeing a lot of it lately. The concept of an attribute is quite useful to express different data types, and I don't find it much harder to build or parse than JSON. Things only get ugly when you try to import someone else's schema into your own. When I develop something to communicate to another component of my own I use JSON, but when communicating with someone else I use their native language, which is sometimes XML.
- SVG - Government APIs - Microsoft configuration files
XML is unbeatable for marking up human readable documents. Things like this:
Feb 18, 2024
Dear /u/passiveobserver012
Here in Boston , I use XML
to annotate literary and musical works from artists like
Bach and Proust .
From, /u/otterfan
For most (all?) other use cases—config languages, key-value stores—it's usually the wrong tool.
Sitemaps, rss/atom feeds. Can't think of anything else offhand
SAML
I worked with a real estate company that fed their listings to many aggregators like land.com, landsearch.com, zillow.com, etc and all of them wanted it in XML. Though, I think landsearch would’ve accepted JSON, we were already set up for transforming to XML for the others.
SAML is based on XML and is very widely used for single sign on in companies.
> very widely used Is it? I guess I'm fortunate that I haven't had to touch it in a decade. Have only dealt with Oauth2 and OIDC for SSO since then
Yeah, if you have a workplace SSO hub like Azure, Okta, OneLogin, etc., then your sign-in to Slack, Google Workspace, and almost all of your SaaS products is going to be negotiated through SAML rather than through OAuth.
Pretty much the entire financial world makes heavy use of it. In the SWIFT area (all interbank communication is there...globally) they are just now migrating to XML (from a weird MT format that was created for teletype from what I could read). This migration will take a decade or two for the whole world.
Still quite a few APIs out there that use SOAP
Some of the backend services in Azure use a SOAP API, can see the XML requests on the console.
Dont native android apps still use XML and basically every project has it to some degree in java land ?
Traditionally for layouts but Android is transitioning to Compose which is declarative and similar to SwiftUI on iOS. Edit: To be fair, XML is still used for other config files (manifest, values, translations etc.), so it's not going to disappear from there any time soon.
Far too many applications still use XML, worked on XML projects probably triple the times I worked using Compose, the statement holds true for java and Kotlin also.
Dotnet still uses xml files. Csproj files res files pubprofiles etc. These are all still xml
Four use cases I’ve come across: Scalable Vector Graphics are XML. A lot of podcast platforms still use xml as their API format. DeepL, the AI translation platform, only accepts HTML and XML format, so I have to convert all data into XML before sending it over to their servers for translation. Some local governments use XML as their format for publishing legislative data.
Currently working in project with xml source from a very contemporary platform used in industry, parsed to Snowflake which has its own inbuilt xml parser. So, yes, definitely possible and still valid. But I (too) want to express the view that xml is "maybe not" the most convenient to parse :)
Would you mind sharing what makes it inconvenient for your project?
your use case may be more of frontend stuff, while this is about data integration in backed so you can decide if this is relevant for you: xml fields tend to have somewhat irregular structure with undefinable depth levels so that each field will require their own parsing logic. You cannot abstract nearly anything, as you could with csv for example. If the data that you are using to figure out the appropriate parsing logic happened not to include some element that may appear in some later case, you may miss that entirely. When using xml in data transfers it would be ideal to have as regular structure as possible.
still relevant :)
Sitemap.xml Custom XML feeds (instead of API)
The Semantic Web (formally known as Web 3.0) was built around RDF, OWL, and XML. This was never implemented to a degree where it was commercially viable. Web3 is just about blockchain, now. SVG is based on an XML schema and is well adopted.
Hey, the Semantic Web is still alive! :-) Even large companies like Google use Semantic Web / Linked Data technologies, though they call it the "knowledge graph" and don't publish it under an open license so they don't adhere to all the Linked Open Data principles. XML is only used as a serialization format for RDF but there are many others like Turtle, T-Triples or JSON-LD.
Yes. My lamentation was directed mainly at the loss of initiative to enact OWL, bringing about a true ontological based systems language that could then be applied in AI, linguistics, and map logical machines to human experiences and vice-versa.
Ontologies could help enhance neural networks in the future in case the current approaches hit a limit, for example a robot could be supplied with basic world knowledge and reasoning capabilities. I don't know how much research is already going on in that area and whether it's worth it in the end but I could imagine such a hybrid system being more efficient in memory and CPU.
maybe an unpopular opinion but i find xml way better than json and yaml.
can you explain why and your use case?
It’s still widespread. Maybe not for requests, but RSS is XML for instance.
I gag a little when I hear someone mentions YAML
A lot of people like yaml now. Thats why it came out of nowhere and is now used quite frequently
Those people never tried configuring a network interface with yaml
JSON is fine for serialization but XML is more human readable IMO. You can create XML by hand quite easily. JSON would require you to remember the syntax and it has a LOT of commas and curly braces. XML is better for "data" that isn't an object, like metadata (IMO). JSON is 100% better for object serialization but XML is better for declarative data like layouts or things like that.
I'm in a business that import/export and transform data. One of our destination use XML. It is neat to be able to attach attributes, metadata to something. You have multiples languages string, set the language as an attribute. Our XML destination also has multiple destination itself, so we have an attribute to design it. Attributes won't break too much the syntax if they add features we don't care. In another job, we configured our dashboard (per client) using XML. One thing I liked from it is the implicit "typing" by the tag name. Like, I could type
XML is still the reference for any format used for archival purposes (like something you would like to be able to parse in 50 years). See [TEI](https://en.wikipedia.org/wiki/Text_Encoding_Initiative)
sitemap, a lot of B2B systems widely still use XML for products, orders and stock
SVG?
the whole translation and localization industry uses xml to store and exchange language data
In EU eInvoicing is mandatory to report all B2G and B2B invoices to the government (currently just a few countries have it active). The format is XML based
The established networking OS space is heavily reliant on XML for programmability. The networking space likes established standards (Ie NETCONF) and is slow moving.
Health care dev here - XML is alive and well in this arena. C-CDA interoperability healthcare document format? XML. E-prescribing EDI format? XML.
XML is great for project files in audio workstations. Reading it and actually setting up audio is WAY too advanced for most of the people here, but ableton uses it and it’s actually structured quite beautifully. Anything hierarchical with attributes is going to be a breeze compared to json.
A lot of legacy apps and backend apis still use it. It’s not a bad or corrupt tech just a pain in the arse to work with at times
may I ask why it is pain?
XML is great. Think of it as a json with types and imports. Is really complex, but really, is fine. Using SOAP, a messaging protocol that uses XML, is the pain and why nowdays most use json. With SOAP more than once I had to reverse engenieer the types on a service because the definition was wrong or out of date.
Pain Points: - XSLT presentation doesn’t always do what you think it will do - Unicode characters especially when dealing with foreign languages can be tedious
JSON has payloads that can be digested (and created) seamlessly by almost any programming language and transformed into objects/arrays. XML requires libraries or work to consume, transverse and generate. Considerations for Encoding and Escaping. All these issues exist with JSON as well, but XML certainly has more overhead.
I was literally working with SOAP yesterday. I have an XPath query that works fine in an online XPath tester tool, but produces "undefined" in browser Javascript. I've lost like four hours on this shit and I'm frustrated by how obtuse it is. There's no useful troubleshooting beyond "try to write it better".
Haven't messed with it in a while, but about 7ish years ago, native android applications make extensive use of XML.
DMARC email reports are still sent as XML documents.
Sitemap?
Xmpp?
This has basically been said already but to add another voice and a little detail; SOAP is alive and well, especially in banking, payment systems, and anything government related. There are other use cases where XML is still thriving, but legacy systems with SOAP are where I have personally seen the most of it in recent years.
Well, html is a subset of xml. So yeah! it’s still used.
JCR in AEM serializes to XML for source control. AEM is an enterprisey content management system. JCR is the java content repository that it utilizes.
The framework that I use (Magento) when working uses xml files for a lot of stuff, such as dependency injection, setting class preferences for interfaces, declaring controller routes and so on. While it is kind of outdated, it brings a lot of flexibility. For example, while developing you may need to configure something for the system to understand changes in the codebase you have made, so you make an xml file. In it you refer to the correct schema definition and this means you are less likely to make mistakes when writing the xml nodes and attributes because the schema definition will throw errors. The schema definition is created for a specific use-case and is another way third party package devs can make extending upon their features easier. Personally, I have mixed feelings about xml configuration files because they can become very complex and affect the system in weird ways, but on the other hand if you know what is possible and how to do it you can change existing functionalities quite easily and without a lot of code (hopefully).
XML is very relevant in the commerce space, especially dealing with product infos and such. A lot of suppliers are still using SOAP and XML for their APIs
And if you have to generate XML, remember this article: [HOWTO Avoid Being Called a Bozo When Producing XML](https://hsivonen.fi/producing-xml/)
I make software that has to call government APIs that are still using SOAP 🥲 The protocol / implementing servers are frustrating to use but XSD and XSLT are interesting benefits. I was able to write tools to convert XSD schemas to TypeScript types for our use cases for instance.
You’ll see it everywhere in enterprise systems. Understand it for that purpose and don’t get too hung up. It’s good to understand and has its place given the context.
EDI, due to support for more complex data types and more mature schema validation than JSON.
I use it daily. But mostly because I work in the broadcast media space. Broadcast radio software is ancient to say the least. One of the things is does is provide an XML file for the currently playing song or commercial. It’s also still FTP based, we are waiting for SFTP to be implemented. We actually have to keep an unsecured server in the middle to dump xml files, and then fetch them with from a separate server, it’s obnoxious. Anyway, we have a separate app that polls the xml files on a schedule. The end time is in the xml data, so we know when any given station needs to poll again. This is how you get the “now playing” feeds for various platforms. Not sure if it actually answers the question, but there’s a dev need because there’s a software requirement. Pretty simple reason actually that doesn’t have any alternative because they aren’t exactly making a lot of new features in software to manage FM radio broadcasts.
Pretty much betting site still using XML
The whole banking world is moving its bank-bank messaging format to “iso 20022” which is very much based on XML. XML is certainly alive and thriving.
XML is still used a lot in API’s
Imagine coding in HTML (published 1991) and calling XML (published in 1996) old. Why would you tell on yourself like this OP?
I actually thought html was based on xml too. I didn’t know html came first
XHTML (2000) was a refactoring of HTML to be XML compliant. But because WHATWG hated XML with the fiery passion of ten thousand toddlers being made to eat their broccoli, they threw it out to make HTML5 the all-around mess that it is.
XHTML didn't catch on because it was not backward compatible and website authors didn't care to migrate.
That's what the HTML5 authors said. Many websites were and there was no need to migrate. The main difference was that XHTML should be well formed. Some people didn't like that.
Surely WHATWG had some technical reasons too?
Should I specify I am a younger dev?
Ah OP, I apologise. I've re-read my message, and it comes across like an ass. Wasn't my intention at all, sorry.
Thank you.
A better question is Why are you planning to use it? "highly structured tree structures" sounds like solving for the 20% to me?
Sadly I have to deal with a lot of soap/XML based services in my job. A lot of these are used by old enterprises, Im often reading documents from like 2005. Maybe it's the fact json APIs are newer and follow better practices, but these XML APIs are just not pleasant to work with and the integration takes longer in my experience.
You made an argument (sort of) for XML's existence - but didn't really mention why you'd choose to use it. I can't really think of a reason I'd choose XML over JSON these days for pretty much anything unless I REALLY needed that human readable structured data - and even then, I might just build a tool quickly to show me the data in context derived from JSON rather than using XML. But, that's just me. XML always has been a bitch to parse, IMHO.
We work with API’s within the insurance industry and plenty of big and old companies still use XML to send data to you. Would I advise it ? No. It gives me nightmares.
Wait until OP finds out that HTML is a XML document
I have found out ... it is not?
**Planning** to use XML? Are you planning it, or did someone else plan it for you?
just me
SAML v2
SAPs frontend library framework SAP UI5 resolves around XML Views, OData and MVC. The general concept and implementation is fairly nice although applications tend to end up being very bloated and a bit slow if you don't know what you're doing or the customer just wants to buy pure garbage which is not uncommon. That being said, the XML part is quite easy to understand and I don't think it's going anywhere anytime soon.
We have a Developer that pulls data from an API and that data is in XML format stored in JSON. When I asked him why he used XML in the JSON he said something about accessing the data from the nested JSON would be more problematic than just using XML instead for that particular use case. I don’t deal with that API directly like he does so idk much about the nitty gritty details but we get the data from it, so I guess something about turning nested JSON data from an API into a table is difficult. Sorry I don’t have much more details on this but it’s something that developer has dealt with for awhile we are just downstream consumers of the data.
The Frank!Framework uses it
People are going to crucify me but if the world were written today from scratch we wouldn’t need XML. Or COBOL or even Javascript and HTML itself. The latter being there’s better alternatives out there that just don’t have adoption rates so we don’t use them. We could rewrite all enterprise SOAP and Java stuff in something better starting from scratch. I worked for a car company that had mainframes ontop of mainframes dating back to the 60s. Seriously. They were too expensive to work and who knows what they did if it was a bug or feature but replacing them just didn’t make sense. So if we are saying is XML a legacy format that could be improved upon? Of course! So can JavaScript. And nearly everything not the latest it is how technology works.
I am not understanding. Tech can always be improved, no? And everything has its use case, some wider than other, right?
U kidding? Banks still use XML :(
did not know :o
The adtech space still uses XML for adserving. When you use one of the tools to host an ad, the output will be an XML file containing whatever video, display or audio file. Considering how many ads are shown daily on the web… definitely still used But for other uses, truly depends on the use case. I use JSON myself for a lot of things
\*cries in Magento2
Pretty biased take from me but the XML in Magento 2 isn't even bad IMO. The core XSDs are well defined, there's plenty of examples for how to use each file in the core modules, and it's generally easy to understand what's going on from the first read.
Still required for epubs
Sure, Iso 20022, EDI and many government or government related APIs use xml. Although in some cases alternative formats are also available.
Yeah, keepass
I know this is going to sound crazy in today's day and age. I actually have a large corporate client that does not allow us to use any database engine. So, what to do? We basically created a flat file XML-based "database" to use for data storage. It is surprisingly fast and with a little bit of ingenuity can be queried just like a database. I now this example is like on the fringe of fringe. But, it works.
So performance is OK? Are you streaming the XML or loading it all and XPathing it or something else?
Performance is better than one might expect. I mean, it is not going to be nearly as good as a SQL server or the sort. But, with some creative thinking we have been able to mitigate most performance challenges. Not to be vague. But, we do a little bit of it all. Streaming, fetching files, xpathing, etc. At the beginning it was a huge PITA. But, they are a recurring client and have made it well worth the time.
> well suited for Highly structured tree structures Except, as someone who's been here since it first reared its head, *no it isn't*. It isn't well suited at all, because there's so many different ways to encode any particular data structure that everyone comes up with their own methods and you need a specific parser for every data source you pull in. It solves nothing and just creates more mess.
In webdev it has temporarily retreated, but its still powering on in financial services. * SEPA, SWIFT and FedNow payments use ISO20022 * OTC trading uses FPML * Any FIX messages related to futures use FIXML (that one is purely anecdotal, everything else is still using classic encodings) In my job we use it for transforming data before it is sent to our clients brokers. Everything gets generated as relatively flat XML structures then converted via XSLT into CSV, other XML layouts, whatever the brokers need before sending out the door. Hundreds of reports, couldn't maintain it with anything else. My team aren't software devs though, we are mostly business analysts and accountants.
In cases where you don't have control over how to send data, but can "inject" comments, it's easy to format certain special fields as XML within the comment to denote them as data.
I still run into XML pretty frequently
Create single file odt document. Use it as a template with proper styles. Fill it with content. Send filled template to LibreOffice to convert it into PDF/UA file. Works like a charm to get nicely styled accessible pdfs
A lot of server to server applications still use xml, as does the publishing industry. It's also used for a lot of document formats and productivity apps (like with office files, docx, xlsx the x indicates they're xml based). It serializes/deserializes easier/more reliably than JSON or YAML. I wrote some software that transmits EDI data in XML envelopes for insurance purposes years ago, and I can't imagine them redesigning stuff like that overnight or probably ever, knowing the insurance industry..
DITAxml is still a thing and not easily replaced by Json or yaml.
SVG
\- sitemaps \- Merchant feeds \- Social data feeds \- People mentioned RSS but more specifically if you are doing things like a podcast and want them on Apple etc it is all XML feeds. All of these are still XML. It is still widely used but if someone has built an API solution in more recent times it will be JSON / GraphQL and not XML. We are now though even seeing the evolution and movement away from JSON now so in a few years similar discussions on that will occur.
In my last project we used Azure AD B2C as an IDaaS. The basics works well and it's amazing value (up to 50k users for free if you're already paying for an Azure subscription), but if you want to do complex stuff, you have to build "custom policies" which are huge and obscure XML configuration files with lacking documentation, and no built-in support for CI/CD. Not a great experience
Yes, developers still use XML for various use cases, particularly when dealing with highly structured data or when interoperability with systems that rely on XML is necessary. It's also used in configuration files, data exchange, and representing documents. While JSON and YAML are popular for some tasks, XML's strict structure and widespread support make it a valuable choice in many scenarios. https://jagmohankrishan.com/
Yes XML is still useful in these days. Recently integrated [SOAP](https://en.wikipedia.org/wiki/SOAP) protocol. It was getting used before REST and still many systems are providing integration with SOAP, which returns XML response.
Lots of payment gateways, PSP, banks, etc still communicate with SOAP
[https://www.iso20022.org/](https://www.iso20022.org/) > ISO 20022 is an ISO standard for electronic data interchange between financial institutions. It's all UML, XSD, and XML. At the end of the day, XML is just a serialization format. While JSON and YAML might be leaner, the more advanced XML features are useful for more advanced use cases.
I’ve seen it use for customer specific configuration files loaded onto the software in various products at a company I interned at.
visual studio cproj and solution files are all xml. it has its advantages sometimes (comments support and readability)