6 ms·

I will risk that this will be an unpopular opinion, but if you are having problem with XML, you are using it to solve the wrong problem. I understand writing X

by sly010 12y ago

I will risk that this will be an unpopular opinion, but if you are having problem with XML, you are using it to solve the wrong problem. I understand writing XSLT and XML Schema can be difficult and I see how typing out XML namespaces can be a pain, but every sentence about XML in that article is a joke. Those quotes are all intended to be funny, not objective. Noone actually brought an objective facts against XML. Because they can't. The fact is it is widely used in many places. Anyone tell me an alternative to serialise an object tree where you also need to preserve ordering and type information, you need to store text longer than one line, or you just need to store any kind of formatting information. (and yes, you can use JSON to do that, but the resulting document will be 5x longer) (meta: Funny quotes bashing useful technologies is the cat video equivalent of HN. Last week's article beating OOP was the same pattern.)

sharpneli 12y ago
Or someone else has used it to solve the wrong problem. Or your customer demands you to solve the wrong problem with XML. A nice example: Simple configuration files which are best described as simply option=value or maybe json if someone wants to go really wild. A customer comes and wants configuration files to be XML. Then your sales department agrees and now you have to implement XML files. The end result: Configuration files are no longer easily editable by humans. Yay! Another example: Someone decided that using makefiles is too hard, so let's make the equivalent but with XML! I'm looking at you ant! Now they're still have the same problems as makefiles but they are much harder to edit.
- crdoconnor 12y ago
  In my experience * Configuration files are best made with YAML (it's the most human readable). * APIs / other forms of serialization/deserialization over a network are best done with JSON (chop it in half and it will fail fast unlike yaml. still fairly readable tho). * Programming languages (like ant) should not be written in either one ever (fortunately I've never heard of a YAML or JSON based language). * XML does a bad to terrible job of all three.
patsplat 12y ago
Agreed. How much XML was used to introduce DSLs and dynamic typing into Java?
crdoconnor 12y ago
Objective facts: * XML is complicated enough that its parsers are commonly full of obscure bugs. JSON/YAML doesn't have this problem. * XML is complicated enough that its parsers can have security vulnerabilities (e.g. see billion laughs for just one). JSON/YAML doesn't have this problem. * XML is complicated enough that you can create an almost-but-not-quite valid encoding. The (already complicated enough) parsers have to deal with this and the ones that don't are considered broken. JSON/YAML doesn't have this problem. * XML's complexity does not give you any additional benefit over YAML or JSON. Serializing/deserializing dates as strings is not a problem. It never was. XSLT is just the shitty icing on the already crappy cake. A committee created a disastrous turing complete programming language to munge this already overcomplicated data format.
- jffry 12y ago
  YAML allows deserialization into arbitrary native types, which most definitely is [1] an issue (see: the flood of Rails/YAML vulns a while back) [1] http://blogs.teamb.com/craigstuntz/2013/02/04/38738/ http://blogs.teamb.com/craigstuntz/2013/02/04/38738/
  - crdoconnor 12y ago
    That is an issue, but it's more of an education/naming issue since it is, after all, intentional. I think it's really dumb that most YAML libraries have a load() and a safe_load(). If they had a load() and a dangerous_load() then the problem basically wouldn't exist.
- personZ 12y ago
  If we eliminated everything where implementations have had obscure bugs or security vulnerabilities, there would literally be nothing left. XML's complexity does not give you any additional benefit over YAML or JSON. This is so incredibly wrong, on every level, that it belies belief and reads like something you would come across on a "beginning programmers" forum. As others have said, JSON/YAML thus far have seen limited usage (no, that configuration file on your app is not a complex example). But as it grows people are starting to ask questions like "Gosh, wouldn't it be nice if my perimeter or the source system via a metadata file could validate the JSON passed to us". "Wouldn't it be nice to be able to convert from one JSON form to another." And the exact same complexity is arising...poorly, and with the same hiccups that the XML system went through. I mean some of the comments are incredible. Like "JSON is simple enough that errors aren't big" -> Hey, sorry that those bank transfer got lost, but it turns out that we mistyped the account number field name and the destination system just ate it. Json. ¯\(°_o)/¯ Sorry that the dates are completely wrong, but all of those years of discovery about time zones and regional settings...just make it some sort of string and they'll figure it out. ¯\(°_o)/¯

by sly010 12y ago

sharpneli 12y ago

Or someone else has used it to solve the wrong problem. Or your customer demands you to solve the wrong problem with XML. A nice example: Simple configuration files which are best described as simply option=value or maybe json if someone wants to go really wild. A customer comes and wants configuration files to be XML. Then your sales department agrees and now you have to implement XML files. The end result: Configuration files are no longer easily editable by humans. Yay! Another example: Someone decided that using makefiles is too hard, so let's make the equivalent but with XML! I'm looking at you ant! Now they're still have the same problems as makefiles but they are much harder to edit.

crdoconnor 12y ago
In my experience * Configuration files are best made with YAML (it's the most human readable). * APIs / other forms of serialization/deserialization over a network are best done with JSON (chop it in half and it will fail fast unlike yaml. still fairly readable tho). * Programming languages (like ant) should not be written in either one ever (fortunately I've never heard of a YAML or JSON based language). * XML does a bad to terrible job of all three.

patsplat 12y ago

Agreed. How much XML was used to introduce DSLs and dynamic typing into Java?

crdoconnor 12y ago

Objective facts: * XML is complicated enough that its parsers are commonly full of obscure bugs. JSON/YAML doesn't have this problem. * XML is complicated enough that its parsers can have security vulnerabilities (e.g. see billion laughs for just one). JSON/YAML doesn't have this problem. * XML is complicated enough that you can create an almost-but-not-quite valid encoding. The (already complicated enough) parsers have to deal with this and the ones that don't are considered broken. JSON/YAML doesn't have this problem. * XML's complexity does not give you any additional benefit over YAML or JSON. Serializing/deserializing dates as strings is not a problem. It never was. XSLT is just the shitty icing on the already crappy cake. A committee created a disastrous turing complete programming language to munge this already overcomplicated data format.

jffry 12y ago
YAML allows deserialization into arbitrary native types, which most definitely is [1] an issue (see: the flood of Rails/YAML vulns a while back) [1] http://blogs.teamb.com/craigstuntz/2013/02/04/38738/ http://blogs.teamb.com/craigstuntz/2013/02/04/38738/
- crdoconnor 12y ago
  That is an issue, but it's more of an education/naming issue since it is, after all, intentional. I think it's really dumb that most YAML libraries have a load() and a safe_load(). If they had a load() and a dangerous_load() then the problem basically wouldn't exist.
personZ 12y ago
If we eliminated everything where implementations have had obscure bugs or security vulnerabilities, there would literally be nothing left. XML's complexity does not give you any additional benefit over YAML or JSON. This is so incredibly wrong, on every level, that it belies belief and reads like something you would come across on a "beginning programmers" forum. As others have said, JSON/YAML thus far have seen limited usage (no, that configuration file on your app is not a complex example). But as it grows people are starting to ask questions like "Gosh, wouldn't it be nice if my perimeter or the source system via a metadata file could validate the JSON passed to us". "Wouldn't it be nice to be able to convert from one JSON form to another." And the exact same complexity is arising...poorly, and with the same hiccups that the XML system went through. I mean some of the comments are incredible. Like "JSON is simple enough that errors aren't big" -> Hey, sorry that those bank transfer got lost, but it turns out that we mistyped the account number field name and the destination system just ate it. Json. ¯\(°_o)/¯ Sorry that the dates are completely wrong, but all of those years of discovery about time zones and regional settings...just make it some sort of string and they'll figure it out. ¯\(°_o)/¯