4 ms·

"In computer science, we had the XML craze at the turn of the century." I'm amazed at how much shade gets thrown at XML (still). The biggest company in world

"In computer science, we had the XML craze at the turn of the century." I'm amazed at how much shade gets thrown at XML (still). The biggest company in world (MSFT) defines their entire office suite in XML. SOAP on the wire is the most efficient M2M protocol for conveying strongly typed message payloads. But to the Author's point, maybe some of the "questions" asked of XML were incorrect.

yason 8y ago
The biggest company in world (MSFT) defines their entire office suite in XML. SOAP on the wire is the most efficient M2M protocol for conveying strongly typed message payloads. That does not point to a particular excellence of XML. XML was designed as a markup language and thus people came up with XML-based domain specific languages with which they could define trees of data and metadata for storage and payloads. So, in effect, what these people are sending back and forth is trees with metadata. You can encode the same information in JSON or S-expressions, and people have already done all that. You just need to agree on conventions for the semantics but that holds even for XML. XML has the benefit of wide support across platforms, good reference implementations originally, various standard schemas for different data, but technically it has nothing revolutionary: rather, as people who do know XML inside out it's overly complex as a base format for data encoding. Writing a parser compliant to the spce is not trivial. XML's best feature is probably the fact that the complexity in the structure and syntax of the language is not enforced and you can easily keep your XML simple. That is what most people actually do. The fact that you can define an office suite in XML is not particularly a merit to XML: Microsoft just decided to use XML to encode their previously binary documents in plaintext. It's not as if they couldn't have done it without XML but some other format, or, defining their formats in XML would somehow make the documents available for anyone to interpret who has an XML parser. The meat is still in the semantics which you have to implement in your export and import code. Whether those semantics are then applied in the form of JSON or XML or pickled Python dicts or whatever is the trivial part.
laumars 8y ago
SOAP and OOXML aren’t exactly the greatest of examples of XML if your point is to defend it. OOXML is so verbose (it’s actually dozens of XML files which are completely incoherent to a human reader) that it needed to be compressed into an archive. Microsoft use the ZIP format for that, so clearly they weren’t going for the best tech possible since otherwise they’d have elected to use one of the many newer and vastly superior compression formats. I’m fact the reason Microsoft moved their Offixe Suite to XML+ZIP is purely because they were ordered to adopt an open standard and they didn’t have any control over ODT et al so created their own competing “open standard” to OpenOffices (this was before LibraOffice was forked). As for SOAP, most devs I know, myself included, hate using SOAP. And it’s certainly not the most efficient way of sending typed payloads - not even remotely. But it is one of the most widespread ways of doing it. However if the history of technology has taught us anything: being in widespread use doesn’t mean it isn’t also complete garbage. I actually do like the founding principle behind XML; but as a specification it’s horrible to implement. As a human it’s horrible to read. And as an engineer, it’s horribly bloated. We have better formats for encoding structured data.

yason 8y ago

The biggest company in world (MSFT) defines their entire office suite in XML. SOAP on the wire is the most efficient M2M protocol for conveying strongly typed message payloads. That does not point to a particular excellence of XML. XML was designed as a markup language and thus people came up with XML-based domain specific languages with which they could define trees of data and metadata for storage and payloads. So, in effect, what these people are sending back and forth is trees with metadata. You can encode the same information in JSON or S-expressions, and people have already done all that. You just need to agree on conventions for the semantics but that holds even for XML. XML has the benefit of wide support across platforms, good reference implementations originally, various standard schemas for different data, but technically it has nothing revolutionary: rather, as people who do know XML inside out it's overly complex as a base format for data encoding. Writing a parser compliant to the spce is not trivial. XML's best feature is probably the fact that the complexity in the structure and syntax of the language is not enforced and you can easily keep your XML simple. That is what most people actually do. The fact that you can define an office suite in XML is not particularly a merit to XML: Microsoft just decided to use XML to encode their previously binary documents in plaintext. It's not as if they couldn't have done it without XML but some other format, or, defining their formats in XML would somehow make the documents available for anyone to interpret who has an XML parser. The meat is still in the semantics which you have to implement in your export and import code. Whether those semantics are then applied in the form of JSON or XML or pickled Python dicts or whatever is the trivial part.

laumars 8y ago

SOAP and OOXML aren’t exactly the greatest of examples of XML if your point is to defend it. OOXML is so verbose (it’s actually dozens of XML files which are completely incoherent to a human reader) that it needed to be compressed into an archive. Microsoft use the ZIP format for that, so clearly they weren’t going for the best tech possible since otherwise they’d have elected to use one of the many newer and vastly superior compression formats. I’m fact the reason Microsoft moved their Offixe Suite to XML+ZIP is purely because they were ordered to adopt an open standard and they didn’t have any control over ODT et al so created their own competing “open standard” to OpenOffices (this was before LibraOffice was forked). As for SOAP, most devs I know, myself included, hate using SOAP. And it’s certainly not the most efficient way of sending typed payloads - not even remotely. But it is one of the most widespread ways of doing it. However if the history of technology has taught us anything: being in widespread use doesn’t mean it isn’t also complete garbage. I actually do like the founding principle behind XML; but as a specification it’s horrible to implement. As a human it’s horrible to read. And as an engineer, it’s horribly bloated. We have better formats for encoding structured data.