Ah, seems like XML has its own dialect of Regular Expressions.
https://www.regular-expressions.info/xml.html
I wasn't aware of that. When I was using "a lot" of XML, the kind of applications and scope of usage did not require schemata to be defined, never bothered, just used it bare.
JSON has become more liked in many places these days, as it's less verbose (all those repeat..../repeat tags in XML...), but still has all the advantages. That was/is not optimal in XML, but as things are, you have to start from somewhere, and XML was designed looking at HTML, and IIRC even initially it was mostly intended for web things, not desktop applications, but it became popular for that, too.
When XML was new, binary formats for everything were king. Next to the not very powerful "*.ini" style text files.
Binary formats are harder to debug. Let alone fix, or create / modify, without custom tools, in case of a partially broken file.
The latter once saved my butt, actually. When developing content creation tools for a new video game in an understaffed, underfinanced startup, and others need to use your stuff ASAP, way before prime time, it can happen that after some work was done, the app crashes. Saved data seems corrupted. I open the thing in a reasonably capable text editor, and after 5 minutes, 2 hours worth of work were saved. That happened a couple times before all was straightened out.
I was very thankful for a text-based storage format
Also, text based formats can be diffed (e.g. git diff, or whatever), to see what changed. Yeah, you could do that with binary files in a hex editor that can do diffs. Way less "fun" and much more error prone, though.
Sometimes even more interesting if source code* management is used: see *who* changed what in a file.
Of course, only, to ask the person kindly what it's about. (nevermind that the command is "git blame", haha.)
* may sound weird, but if you're developing content for a product, which is stored in a text-based structured file, that that's also a kind of "source", and it makes sense to put it under versioned source code management such as git (which, incidentally, does handle binary files absolutely poorly - for game media assets, SVN, which does that well, was used - but that's about its only saving grace)
The same goes for MSWord docs etc, their XML based formats.
While the exact, hierarchical layout of a XML file format (as e.g. defined by a schema... or just... the fact that your program writes / reads in that kind of a structure) is application specific, the fact that there are elements to define a hierarchical structure of arbitrary complexity, and some "optimizations" for common occurrences (e.g. attributes of tags, instead of having to use own tag levels for every little thing), are universal.
That means that there can be an XML library for a programming language, which does the basic reading/writing (and validation of adherence to / integrity of the application specific format via schema) of such a structure, correctly.
So at least the handling of a big part of your custom format is outsourced, and shared between possibly many different custom formats of yours.
Or somebody else's, that you want to read/write, and don't want to implement a parser for on the byte level.
A lot of software started to use it instead of binary formats, where sizes is not really an issue. E.g. saving/loading settings for applications, storing data where the amount is not so big that it will be gigabytes. Documents like of the MS Office suite and similar.
If things do get too big, you can still compress it using a standard, open compression format for which libraries exist - as you can imagine, it compresses rather well.
https://stackoverflow.com/questions/1082285/best-compression-algorithm-for-xml
Some comments there lamenting how this defeats the purpose - well, not so. Using standard compression formats will still yield the magic of a custom format that yet everybody can write and read, because for the XML inside, as well as the (de-)compression algorithm, standard tools available for everyone are used.
But now looking at this: really a lot less verbose
https://en.wikipedia.org/wiki/JSON#Example