Hacker News Reader

Comment by dstein | Hacker News Reader

It boils down to JSON being schemaless. In XML the data type is implicitly defined by the tag, whereas in JSON you need to arbitrarily encode the datatype as a property and somehow differentiate between properties and child elements/objects.

View on HN

How about this?

    <Foo1 name="foo1">
        <Bar1 name="bar1"/>
    </Foo1>
    <Foo2 name="foo2">
        <Bar2 name="bar2"/>
    </Foo2>


    [["Foo1", {"name" : "foo1"}, [
        ["Bar1", {"name" : "bar1" }]
     ],
     ["Foo2", {"name" : "foo2"}, [
        ["Bar2", {"name" : "bar2" }]
     ]]

I personally wouldn't do this, but the arbitrary encodings between the two samples are now equivalent.

No, I think you proved my point.

I still don't understand. What makes the XML version better than the JSON version? Why is creating XML like that a good solution, while creating JSON like that is not?

The XML is better because when the data types directly relate to tag names it is simple to understand, read, and write, process, and there are tons of XML libraries in every language that do object-xml serialization automatically. With JSON, since there are no types, you must manually write your own data-object serialization and embed the type system right into the data structure itself.

It sounds like that might be better for a statically-typed language where you might need specific types in the data file. But I would argue that not only is it overkill in a dynamically-typed language, it's bad. We're talking about data here. There's no reason to couple it to data types in your code.

Plus, serialization to JSON in a dynamically-typed language is pretty much automagic compared to what you have to do with XML.

Reply on news.ycombinator.com