Hacker News Reader

- JSON just has UTF-8. XML has encoding madness.

- JSON has just one escape format and all unicode codepoints can be used. XML generally allows only certain unicode codepoints, at some places like element names its further restricted (Quick: Which characters are not allowed? What's the difference between XML 1.0 and 1.1 here?). XML escapes at every place differently. In comments you need to escape less than elsewhere. In attributes you can use newlines but they will get normalized to spaces, you have to hex-encode newlines. There's Cdata.

- JSON doesn't have the entity madness with potential security issues.

- JSON doesn't have namespaces that add a lot of complexity with little benefit

JSON maps nicely into a python dictionary.

JSON is arguably easier to read than XML

> - it's confusing what should be a text inside a tag versus a tag attribute. Or should that text be parsed into a number? At least JSON is strongly typed, you know what datatype is what just by looking at it.

JSON's types are pretty anemic compared to the XMLSchema's datatypes[0]. Even it you don't use all of XSD's complex type system, having these basic datatypes is extremely useful and I wish JSON had similar.

[0] https://www.w3.org/TR/xmlschema11-2/

> JSON's types are pretty anemic compared to the XMLSchema's datatypes

The same thing is true if you replace “JSON” and “XMLSchema” with “XML” and “JSON Schema”, respectively.

And also, though less so, if you do the same but replace “XML Schema” with “JSON” instead of “JSON Schema”.

JSON can't express ordering or duplicate fields in a consistent way.

Consider how you'd write these 2 bits of XML in JSON:

vs.

Without a schema, in the first case, how do you determine whether B should be "foo" or ["foo"]? In the second how do you preserve the relative ordering of B #1, C and B #2?

I worked on a project where we had a parse tree that we wanted to serialize out, and for this reason XML was the natural choice.

So this is exactly a symptom of unclarity of the roles that xml causes in the first place. It seems like You're trying using the tags as keys instead of as information categories. In json you might encode these sorts of data as something like (pardon my lack of quotes, I'm on mobile):

    {a_list:[{text: too, type: b}, {text: bar, type: c}, {text: uh_oh, type: b}]}}

But generally you shouldn't have a mixed type list in json unless it's a deliberate choice, the "limitations" of json are exactly what devs want because it corresponds to a clarity of thought and purpose that simply isn't there in XML.

In my case the parse tree had nodes that corresponded with grammar rules (mapped to XML elements) and nodes that corresponded to the preserved but otherwise uninteresting fluff that surrounded them (mapped to XML PCDATA).

We wanted a parse tree that could be serialized out to produce the original document byte for byte, but still reflected the grammar.

Things get uglier for JSON in the real world case:

    "5+7 #comment"

becomes:

    <sum><integer>5</integer><operation>+</operation><integer>7</integer> #comment</sum>

The XML output is essentially the original input + grammar markup. Your solution also works but is a data structure representation with a lot more line noise for humans to read.

It just looks bad because I made it one line; by comparison if I hadn't seen the pre-parsed form 5+7 I would not be able to immediately grok what is going on in your parsed one-line XML, either; there's a lot of "line noise" there too. Moreover it feels like the XML you have has lost the structure of the meaning, by having the tokens 5, +, and 7 be linearized. You probably want a tree with + at the root and 5 and 7 as leaves. That XML encourages these sorts of "oddly flat" representations is one of its weaknesses.

+ at the root would indicate an abstract syntax tree rather than a concrete or "full" syntax tree (terminology varies slightly)

This was primarily a mechanism to load parsed documents in to code that didn't have access to the recursive descent parser that parsed the document, for either security or performance reasons.

Loading the XML with the appropriate parse flags, doing a pre-order traversal on all the leaf PCDATA, and then printing it out, would regenerate the original document byte for byte.

Perhaps I should go back and implement JSON output and see how I feel about it... thought I'm pretty sure once you introduce a bunch of "text" and "type" fields to the JSON tree it's going to look a lot less readable than XML markup.

There are other fields as well like line and column numbers (output as XML attributes)

While I agree that XML has muddy-thinking whether tags are types within a collection or properties of an object, I've often felt that Json's inability to store heterogeneous object arrays meaningfully is a big problem. The lack of a meaningful "type" attribute in JSON schema is a pain.

I've had to roll my own hack for such cases.

> Without a schema, in the first case, how do you determine whether B should be "foo" or ["foo"]? In the second how do you preserve the relative ordering of B #1, C and B #2?

Well, if you are literally developing a model for recasting general XML in JSON, then you know the children of an entity should be a list because duplication os possible and order is signifcant. (Given the close relationships between XML and HTML and between JS and JSON, the obvious starting point for a general solution is to copy the HTML DOM, using only the properties.)

If you are trying not to reserialize XML generally but to solve the same problem as the original XML, then you probably aren’t doing it without a (logical) schema—you know what the object model is that you are trying to stuff into JSON, and you decide based on that.

{ "a": [ { "b": "foo" }, { "c": "bar" } ] }

vs.

{ "a": [ { "b": "too" }, { "c": "bar" }, { "b": "uh oh" } ] }

> { "a": [ { "b": "foo" }, { "c": "bar" } ] }

This looks like line noise to me. All that punctuation and quoting looks ridiculous. What is the problem with straightforward and trivial to parse things like

    [a]
    b = foo
    c = bar

or even

    a.b = foo
    a.c = bar

Yes, so in essence:

- Only ever have a single key in each JSON object (treating them as tuples)

- Make all object values arrays.

It makes for some very unnatural looking JSON.

> It makes for some very unnatural looking JSON.

Not to me; its a fairly standard and natural JSON pattern. It’s tue that it use is usually quite limited in any given representation, but usually the thing you are modelling in JSON isn’t general XML with no further knowledge of application domain or logical schema.

The only thing that doesn't look natural to me is that it's all on one line.

Otherwise it's very clear about the data's format and when there's ordering required