Thanks for this, it's really neat to learn some of the history behind XML. With such an interesting past and noble goal, it's a shame that it's such a pain to work with these days. Working with...
Thanks for this, it's really neat to learn some of the history behind XML. With such an interesting past and noble goal, it's a shame that it's such a pain to work with these days. Working with JSON in Python is as simple as data = json.loads(json) and then it's a dictionary, same as any other. Obviously, it's easiest to work with in JS, and the author mentioned Go, where a staticly-typed language loads JSON without a lot of hassle. XML though, is far, far less pleasant. There are good libraries out there for reading it in Python to try to make it not so bad, but dealing with it in Java means a lot of time copy-pasting from other projects or SO.
One thing I read that I didn't really agree with is this:
XML didn't turn out to be a great language for defining your build system configs
I don't know which systems the author is talking about specifically, but for all the trouble that I've had from Maven over the years, most of the time it just works, and does what it's supposed to without much fuss. Additionally, Jenkins stores job configurations in XML, and it's pretty prevalent.
Re. XML. One XML technology that I wish was reinvented is in-browser XSLT. You know how Angular, React, and all that allow you to take a "template" HTML and a piece of "data" in JSON, and smack it...
Re. XML. One XML technology that I wish was reinvented is in-browser XSLT. You know how Angular, React, and all that allow you to take a "template" HTML and a piece of "data" in JSON, and smack it all together to get a web page? Well, XSLT allows you to do it to, but it's a part of your browser, not a third-party library. The syntax is heck, and, as is the case with many declarative languages, big XSLT programs are barely debuggable, but this was true decoupling of data from representation, making the web more cache-friendly.
XML is often a PITA to work with. The language is rather ugly. But the intention behind it was beautiful.
DTDs (document type definitions—and formal schema definitions in general) are really useful. Unfortunately, too many software developers make it through school/training without learning any formal...
DTDs (document type definitions—and formal schema definitions in general) are really useful. Unfortunately, too many software developers make it through school/training without learning any formal language theory. Data validation becomes trivial if someone bothers to spend the time up front to formally define data types. This is one thing that I wish JSON had: a singular standard for specifying a schema. Parsing JSON is not hard—in fact, it’s so easy, I’d argue that’s probably why JSON has been so successful. And leaving schema validation as optional would also be perfectly fine (if people want to shoot themselves in their extremities, they’re free to do so). But, I think JSON would be a near perfect data interchange format if there was a universally acceptable way of validating JSON data. Having to infer the semantics of custom JSON data types from examples, or worse, by trial and error, is real pain. JSON Schema is nice, but not everyone uses it (or is even aware of it), so it can’t be relied on.
Thanks for this, it's really neat to learn some of the history behind XML. With such an interesting past and noble goal, it's a shame that it's such a pain to work with these days. Working with JSON in Python is as simple as
data = json.loads(json)and then it's a dictionary, same as any other. Obviously, it's easiest to work with in JS, and the author mentioned Go, where a staticly-typed language loads JSON without a lot of hassle. XML though, is far, far less pleasant. There are good libraries out there for reading it in Python to try to make it not so bad, but dealing with it in Java means a lot of time copy-pasting from other projects or SO.One thing I read that I didn't really agree with is this:
I don't know which systems the author is talking about specifically, but for all the trouble that I've had from Maven over the years, most of the time it just works, and does what it's supposed to without much fuss. Additionally, Jenkins stores job configurations in XML, and it's pretty prevalent.
Re. XML. One XML technology that I wish was reinvented is in-browser XSLT. You know how Angular, React, and all that allow you to take a "template" HTML and a piece of "data" in JSON, and smack it all together to get a web page? Well, XSLT allows you to do it to, but it's a part of your browser, not a third-party library. The syntax is heck, and, as is the case with many declarative languages, big XSLT programs are barely debuggable, but this was true decoupling of data from representation, making the web more cache-friendly.
XML is often a PITA to work with. The language is rather ugly. But the intention behind it was beautiful.
DTDs (document type definitions—and formal schema definitions in general) are really useful. Unfortunately, too many software developers make it through school/training without learning any formal language theory. Data validation becomes trivial if someone bothers to spend the time up front to formally define data types. This is one thing that I wish JSON had: a singular standard for specifying a schema. Parsing JSON is not hard—in fact, it’s so easy, I’d argue that’s probably why JSON has been so successful. And leaving schema validation as optional would also be perfectly fine (if people want to shoot themselves in their extremities, they’re free to do so). But, I think JSON would be a near perfect data interchange format if there was a universally acceptable way of validating JSON data. Having to infer the semantics of custom JSON data types from examples, or worse, by trial and error, is real pain. JSON Schema is nice, but not everyone uses it (or is even aware of it), so it can’t be relied on.
Huh, actually makes me think that it could be worth learning to write a chain-of-blocks based solution to a problem! Wild.