Hacker News Reader

Comment by fergie | Hacker News Reader

The author forgot to mention one the biggest functional benefits of XML which is interpolation: the ability to drop XML components into the middle of text, thereby allowing for markup and nesting of elements in text.

<tag>

  This text node contains <magic>unicorns</magic> and <magic>fairy dust</magic>.

</tag>

There is (as far as I know) no sensible way to add the magic above in JSON or YAML.

View on HN

Here’s the thing: each element needs to know what type its children are. Does it contain only text nodes, or can it contain elements? You can’t just put markup in a place that’s only equipped to handle text and expect it to do anything but explode in interesting ways. (“Interesting” as in “may you live in interesting times”.)

The same can be applied to other formats like JSON and YAML: if it contains only text, use a string, otherwise use an array of strings or objects of some defined structure. Here’s one possible representation:

  {
    "tag": [
      "This text node contains ",
      {"magic": "unicorns"},
      " and ",
      {"magic": "fairy dust"},
      "."
    ]
  }

So I don’t consider what you describe to be a benefit of XML at all, except inasmuch as its syntax can be subjectively a little prettier.

A good example of JSON stupidity. Square brackets introduce an array, whose elements should be of consistent types. But actually this is not enforced. It only enforces the ordering of elements, which adds quite a bit of information! So this is a list (called an array).

Curly brackets introduce an "object", whose fields are considered unordered. So you are not supposed to have multiple "tag". What happens if this is the case ... unspecified!

JSON is probably worse than XML here.

Is your objection to json arrays only that they are not called lists?

That is one of them. Bad naming is a disease in the SW industry and here is a good example. I also argue the square bracket notation is introduced for little effect.

Add nesting to the xml and the array of array of arrays starts to look a lot worse.

This is like a strictly worse kind of s-expression. C.f.

    (tag "This text node contains" (magic "unicorns") " and " (magic "fairy dust"))

It is always sad and funny watching the world churn through inferior plain-text-structured-data solutions, while studiously ignoring s-expressions.

Shameless plug: https://github.com/jerome-jh/s_expression

>[…] the ability to drop XML components into the middle of text, thereby allowing for markup and nesting of elements in text.

Is that “allowing” for markup, or is it exactly what an Extensible Markup Language was intended and designed to do? I wouldn’t expect a JavaScript Object Notation to be able to do that ergonomically.

XML’s design as a markup language, and not an object or config language, is clear even in that example. The first character of the contents of `tag` is newline.

Right, this, and the lack of typing in XML, are the fundamental differences and the sources of many of the differences in performance, complexity, etc. The question to ask is, what’s the right format for your software’s needs? More often than not, programmatic data structures map more directly to JSON/YAML’s simple and typed fundamentals. That easy mapping plus far better performance are the reasons why people avoid XML these days.

The author of this piece gets it fundamentally wrong in saying that “Enterprise” stink was the reason people abandoned XML. For enterprises that need those features, XML is still a fine format to use. But for most purposes, those features aren’t necessary, and the massive overhead that comes along with them makes it a bad tradeoff.

This example should that XML is decent as markup but for a configuration or data interchange format this kind of syntax is undesirable.

You have text with interspersed elements with the same name, how can this be represented in python other than a DOM?

One of the other benefits of XML the author mentions solves this: if you don't want it, disallow it in your schema.

If I disallow everything I don't want from XML I just end up with a more verbose json that is harder to work with.

That's fine, then XML wouldn't be the proper tool for you and you shouldn't be using it, but I was responding to someone saying that they didn't want a specific thing (non-text inside certain tags) which XML supports.

The old saying is XML is a markup language, JSON is an object notation.

Json is not about markup and shouldn't inject surprise objects into the middle of strings. You wouldn't use json for this.

Reply on news.ycombinator.com