XML: Contrary to popular belief, it doesn't always kill babies

Re:XML: Contrary to popular belief, it doesn't always kill b... by Groxx on Saturday February 19, 2011 @07:19PM (#2240409)

Agreed. But isn't a language defined largely by what people are willing to do with it? XML has some wonky specifications that ultimately mean parsing XML is entirely indeterminate - external, over-http schemas, for instance. If every JSON parser in the world accepted single-quotes for keys, wouldn't that imply JSON supports single-quotes for keys? Would every subsequent parser that supported single-quoted keys be wrong for doing so? Same thing for namespaces: because people have abused them so horribly, they're almost useless.

XML libraries have been around for a long time. As have problems with XML libraries. Apparently it's not correctable over time, there's too much legacy to fight against.

---

>I say use JSON now unless you are actually dealing with marked-up text, in which case XML is superior.

I've heard that argument before. How, precisely, is it superior? It's denser than would be doable in my example, but is denser better? A lot of the arguments around both languages revolve around human vs computer readability. Is <em>text</em> more computer-readable than {#:"em", $:"text"} ? A bit more human-readable, yes, but I'll take "text" over either as often as I can.

[ Parent | on HN ]

Re:XML: Contrary to popular belief, it doesn't always kill b... by true_religion on Saturday February 19, 2011 @08:44PM (#2240653)

> But isn't a language defined largely by what people are willing to do with it?

This isn't true for a formalized language. Heck, it isn't even true for FRENCH where there is an official bureau that determines what is "proper" french, and any deviations from it are not part of the standard language.

> If every JSON parser in the world accepted single-quotes for keys, wouldn't that imply JSON supports single-quotes for keys?

It might in the absence of a formal spec, but not all JSON parsers accept single quotes.

For example, the official Python JSON parser does not.

>>> import json >>> json.loads("{'foo':'bar'}") ValueError: Expecting property name: line 1 column 1 (char 1)

I question how many other highly popular languages have JSON parsers built to the spec.

[ Parent | on HN ]

Re:XML: Contrary to popular belief, it doesn't always kill b... by Groxx on Saturday February 19, 2011 @09:05PM (#2240700)

Tons of highly popular languages don't have XML parsers built to the spec. Very few of them can handle schemas at all, or recursive definitions in schemas, or external document types, or external entities or schemas (and the few that can are usually disabled intentionally, because they can make parsing a tiny XML file take minutes if the server of the schema doesn't serve it up fast enough). That the XML spec defines such things is irrelevant if they're wholly unreliable because enough parsers refuse to handle them. And there are more than enough horror stories out there to argue that a significant amount of systems don't handle to-spec XML.

There are plenty of RFCs out there that define things that no longer practically exist - should they be used, because the spec defines something that you need? Especially if it's meant to be used as an interchange format?

[ Parent | on HN ]

Re:XML: Contrary to popular belief, it doesn't always kill b... by saurik on Sunday February 20, 2011 @04:41AM (#2241526)

And if JSON did all of those things the libraries that implemented it would suck as well: the complexity comes from the semantics of what all of those things are and do (schema validation is a complex problem, and that has nothing to do with whether you are validating XML or JSON), not how to parse a silly file format.

Hell: a lot of highly popular languages, to be quite honest for a minute, probably don't even have compliant JSON parsers. The real problem here is cowboy developers who think "oh, JSON/XML/whatever is easy, I can throw one of those together in a few minutes" and then /don't even read the spec/ before committing their project into some poor language's standard library.

[ Parent | on HN ]