5 ms·
XML's curse was that it started with all of the complexity that everyone will eventually add to any possible replacement. Worse still, people felt compelled to
by taeric 3y ago
XML's curse was that it started with all of the complexity that everyone will eventually add to any possible replacement. Worse still, people felt compelled to use every feature that they could for esoteric reasons. Even worse, the big companies did not actually work well with each other's document definitions. Even ones that were supposed to work well together.
That said, you only need to look at the abomination that is an OpenAPI spec that has been annotated to work with AWS to see that the pitfalls are still mostly the same today. (I can also complain about the breaking changes from the old specs.)
- smarx007 3y agoAnd what happened since to JSON and YAML? JSON schemas to replace XSD, YAML/JSON templating to replace XSLT, jq to replace XPath.
- pjmlp 3y agoYeah, it keeps being reinvented, badly.
- nomel 3y agoI used XSD templates once. It was really incredible, how useful it was. Nobody understood it, and rewrote it in JSON.
- lmm 3y ago> JSON schemas to replace XSD Mostly unused. > YAML/JSON templating to replace XSLT Generally much more user-friendly. > jq to replace XPath And much better at it, if only due to not shooting yourself in the foot by default with namespaces. The problem with XML isn't that it supports schemas and namespaces. The problem is that it forces everyone to pay the costs of those things up-front, even if they don't use or care about them.
- smarx007 3y agoAnd because nobody wants to pay the namespace cost upfront, we all end up with vin, vin_no, viNumber, vinNum etc instead of iso3779:vin, for example. Every time we work with more than one API, it's prudent to try aligning the terms used by those APIs.
- lmm 3y agoIn my experience you have to have the duplication before you factor it out; trying to design those terms up front when you have no use cases, or even one use case, is doomed to failure. So you're always going to need to start with something non-standard, figure out the standard based on that experience, and then migrate to align to the standard.
- taeric 3y agoRight, this is pretty much exactly what I meant by XML started with all the complexity that other things will add. I will happily cede that data is a huge area where "duck typing" is far and away the correct choice. Taxonomies of data fail all the time. With odd rules that are largely defined by their exceptions.
- Tao3300 3y agoI might be a sick mfer, but I must confess, I kinda like XSLT.
- Turskarama 3y agoI have yet to see anyone else duplicate the headache that is namespaces, or the distinction between attributes and nested tags.
- taeric 3y agoJSON has several efforts to add namespaces to JSON. JSON-LD seems as complicated as I remember XML being.
- marcosdumay 3y agoXML is full of complexity that it shouldn't have and any competitor would be stupid to adopt. For example, either your format is a programing language, or the data evaluation must never need an internet connection. XML isn't one, yet still requires it.
- taeric 3y agoXML doesn't require an Internet connection?
- pimlottc 3y agoDepending on what you’re doing with it, you may need to download an external schema.
- taeric 3y agoOr you can have it local. And if you are using schemas, it would make sense for you to have them local for validation during tests and such.
- marcosdumay 3y agoIf you want to implement the standard, you parser must be prepared to download extra data when the file requires (it doesn't actually need to download schema, even though it's the naive way to implement it). A lot of parsers do not implement the standard, and they are better for it, because this can create huge security issues. But it's something you have to be always aware of, and could change on any minor version update.
- taeric 3y agoRight, if you are willing to validate any and all random documents, you will have to have some sort of way to get the schemas. I can think of very few reasons to validate unknown schemas in an application, though. Would be like allowing your parser to take in external entities. Can be useful and there are valid reasons for trusted sources. But not for random documents from the web. So, agreed it is a bit of a footgun.