* The likelihood that you will receive badly formed XML and be forced to parse it anyway.
* The multiple different ways of escaping characters.
* Language identification
...I could go on.
Oh, and your parser has to handle ALL of this. It's no good assuming that "since the basics are fairly basic it doesn't matter". It doesn't matter only when you're generating XML, but somebody SOMEWHERE is going to have to consume it.
Wanna know why it's typically possible to blow up an XML parser with a memory leak or a buffer overflow but not a JSON parser? This complexity is why. Just using it creates an increased attack surface for your internet facing API.
>Just curious, do you hate HTML for similar reasons as well?
I'm not its biggest fan, and I feel like it could have been done a lot better. However, A) there isn't much alternative so bitching about it it somewhat pointless and B) at least I never have parse it (want an exercise in frustration some time? try doing THAT...).
I was mentioning the "99.9%" use case of XML for e.g., a resume format. You don't have to specify DOCTYPEs, namespaces, etc.
> The likelihood that you will receive badly formed XML and be forced to parse it anyway.
You're supposed to fail on badly-formed XML!
> Oh, and your parser has to handle ALL of this.
So? I don't have to write an XML parser because there are numerous well-tested ones already written. I wouldn't write a JSON parser for the same reason.
> Wanna know why it's typically possible to blow up an XML parser with a memory leak or a buffer overflow but not a JSON parser?
First of all, you shouldn't speak in absolutes. You certainly could write a JSON parser that blows up for the same reasons. There's nothing inherent in JSON that makes it impossible to write a bad parser.
> at least I never have parse it (want an exercise in frustration some time? try doing THAT...).
For anything more than a trivial format you can automatically have the parser bind the content to a POJO (or your language's "plain old object" analogue).
* DOCTYPE
* Namespaces and namespace collision handling.
* The likelihood that you will receive badly formed XML and be forced to parse it anyway.
* The multiple different ways of escaping characters.
* Language identification
...I could go on.
Oh, and your parser has to handle ALL of this. It's no good assuming that "since the basics are fairly basic it doesn't matter". It doesn't matter only when you're generating XML, but somebody SOMEWHERE is going to have to consume it.
Wanna know why it's typically possible to blow up an XML parser with a memory leak or a buffer overflow but not a JSON parser? This complexity is why. Just using it creates an increased attack surface for your internet facing API.
>Just curious, do you hate HTML for similar reasons as well?
I'm not its biggest fan, and I feel like it could have been done a lot better. However, A) there isn't much alternative so bitching about it it somewhat pointless and B) at least I never have parse it (want an exercise in frustration some time? try doing THAT...).