Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> You've forgotten:

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).



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: