Yes XML is human readable but so is comma delimited text and properties files.
XML is bloated, hard to parse, hard to modify in code, plus a ton of other problems that I
I'd guess that its popularity orginally stemmed from the fact it solved the right problems in a way that wasn't exceeding bad for enough big players to gain their support and thus gain Widespread industry adoption. At this point, it's rather strongly embedded into the landscape since there's so much component development invested around XML. The HIPPA and other EDI XML schemas and adapters that ship with MS BizTalk Server (and BizTalk itself) are a great example of the mountain that's been gradually built on top of XML.
Compared to some of the previous standards it's a dream.
Try writing HDF (Hierarchical Data Format) files or FITS. FITS was standardised before the invention of the disc drive - you have to worry about padding the file into block sizes!
Even CSV isn't as simple. Quick question, whats the separator in a German CSV file?
A lot of the complaints about XML are from people who use it to transfer data directly between machines where the data only exists for milliseconds. In a lot of areas the data will have to last for 50-100 years and be far more valuable than the machine it ran on. It's worth paying a closing tag tax sometimes.
It is a text format that is one of it's major advantages. All binary formats are usually much smaller but you always need tools to "read" them. You can simply open and editor and modify XML files to your liking. However I'd argue it's stil a bloated format, but well you can compress it quite well.... if one looks at the specs for the Windows Office XML formats one just can imagine it's wonderful to be seemingly open....
Regards Friedrich
It's structured.
XML provides a very straightforward way to represent data. Parsing is fairly easy - it's a very regular grammar and lends itself to straight forward recursive descent parsing. This makes it easy for data consumers and producers to exchange information without really having to know too much about their respective applications and internals.
It is, however, an extremely inefficient way to represent data and lends itself to being abused horribly. An example of this is an object interface I worked with that, instead of exporting constructors and properties for particular objects, required me to author XML programmatically and pass in the resulting XML to the single constructor. Similarly, XML does not lend itself well to large data sets that may require random access without creating an added cataloging system (ie, if I have a thousand page document in XML, I will need to parse nearly the entire file to get to page 999, assuming the page data is ordered), whereas I'd be better off putting the actual page data in a separate file or files and use the XML to point to the correct file or position within a file.
It was the late 90s and the internet was hot hot hot, but companies had systems that couldn't get anywhere near the internet. They had spent countless hours dealing with CORBA and were plotting using Enterprise JavaBeans to get these older systems communicating with their newer systems.
Along comes SGML, which is the precursor to almost all markup languages (I'm skipping GML). SGML was already used to define how to define HTML, but HTML had particular tags that HAD to be used in order for Netscape to properly display a given webpage.
But what if we had other data that needed to be explained? Ah ha!
So given that XML is structured, and you can feel free to define that structure, it naturally allows you to build interfaces (in a non-OO point of view). It doesn't really do anything that other interface languages already do, but it gave people the ability to design their own definitions.
Interface languages like X12 and HL7 existed for sure, but with XML people could tailor it to their individual AIX or AS/400 systems.
And with the predominance of tag language because of HTML, well it was just natural that XML would get pushed to the forefront because of its ease of use.