Hacker News Reader

Comment by KKKKkkkk1 | Hacker News Reader

Why does this have to turn into an XML bashing thread? Writing the above equation in JSON would be just as terrible.

> Writing the above equation in JSON would be just as terrible

Not quite as bad as XML.. I think the problem is more the verbose, overly-nested format that was chosen for MathML than XML itself though.

  {
    "mrow": {
      "mi": [ "x", "=" ],
      "mfrac": {
        "mrow": {
          "mi": [ "−", "b", "±" ],
          "msqrt": {
            "mrow": {
              "msup": {
                "mi": [ "b", "2" ]
              },
              "mi": [ "−", "4ac" ]
            }
          }
        },
        "mi": "2a"
      }
    }
  }

JSON object properties are unordered per the spec. This is not portable.

What you have doesn't work. What if I have "mi, mo, mfrac, mo, mi" at the top level? So something like "a - b/c + d". You can't specify the same key twice in JSON. Also, keys are technically unordered, so there's no guarantee that a parser will put that top-level "mi" before the "mfrac".

JSON is great at many things, but polymorphic substructures are AFAIK only really possible with everything being an object defining the "type" that it is. And that looks significantly uglier than what you have above:

    {
        "type": "mrow",
        "children": [
            {
                "type": "mi",
                "identifier": "x"
            },
            {
                "type": "mo",
                "operator": "="
            },
            {
                "type": "mfrac",
                "rows": [
                    {
                        "type": "mrow",
                        "children": [
                            {
                                "type": "mo",
                                "operator": "-"
                            },
                            {
                                "type": "mi",
                                "identifier": "b"
                            },
                            {
                                "type": "mo",
                                "operator": "±"
                            },
                            {
                                "type": "sqrt",
                                "expression": {
                                    "type": "mrow",
                                    "children": [
                                        {
                                            "type": "mi",
                                            "identifier": "b"
                                        },
                                        {
                                            "type": "msup",
                                            "expression": {
                                                "type": "mi",
                                                "identifier": 2
                                            }
                                        },
                                        {
                                            "type": "mo",
                                            "operator": "-"
                                        },
                                        {
                                            "type": "mi",
                                            "identifier": "4ac"
                                        }
                                    ]
                                }
                            }
                        ]
                    },
                    {
                        "type": "mi",
                        "identifier": "2a"
                    }
                ]
            }
        ]
    }

While this format is more generic, an abbreviated encoding can sometimes accomplish the same thing. For example, just moving the "type" to be the object key and removing the implied secondary name gets you this far:

    { "mrow": [
        { "mi": "x" },
        { "mo": "=" },
        { "mfrac": [
            { "mrow": [
                { "mo": "-" },
                { "mi": "b" },
                { "mo": "±" },
                { "sqrt": {
                    { "mrow": [
                        {"mi": "b"},
                        {"msup": { "mi": 2 }},
                        {"mo": "-"},
                        {"mi", "4ac"}
                    ]}
                }}
            },
            { "mrow": [
                {"mi": "2a"}
            ]}
        ]}
    }

It's not as general, but works if you know your syntax is similarly bounded. I don't know how certain static languages would handle serial/deserializing, but makes construction via javascript literals much more pleasant.

Sure, that works as long as each type only has one property. Decoding it might be problematic; I don't know any serializers that would handle that kind of mapping natively.

FWIW, this would be a literal s-expression translation:

    (mrow (mi x)
          (mo =)
          (mfrac (mrow (mo -) (mi b) (mo ±)
                       (sqrt (mrow (mi b) (msup (mi 2)) (mo -) (mi 4ac))))
                 (mrow (mi 2a))))

And this would be a saner one, where mrow is implied:

    ((mi x) (mo =) (mfrac ((mo -) (mi b) (mo ±)
                           (sqrt (mi b) (msup (mi 2)) (mo -) (mi 4ac)))
                          (mi 2a)))

I think either of those is clearly and inarguably superior.

S-expressions are the better alternative to XML.

That's as bad as the XML. Actually it's worse, because your ordering is undefined which breaks everything. They are both nearly unusable by humans.

Basically the problem is this: Either you explicitly represent the grouping in a general scheme capable of it, then you get the disaster (from the point of view of human readable and manipulable) that is XML or JSON. Or you use a domain specific language like LaTeX or whatever, with the attended parsing issues,etc.

If you want people to edit it by hand, the latter option is much better - but it has it's pain points. You don't get to use a broad range of robust tools to manipulate them, for one thing.

Have a go at trying to convert a complex TEI or Docbook document to JSON; you will want to put a gun to your head before the day is out.

Reply on news.ycombinator.com