XML? Be cautious | Hacker News Reader

XML? Be cautious

blog.pragmatists.com

90 pointsbemmu22 comments

The idea of XML, namely typed, semi-structured data with namespaces, was a good one. What sucks is the particular implementation chosen. XML is implemented using SGML, a completely archaic, overly general beast that gives us DTDs, entities and countless other warts that make exhaustively parsing and handling XML the insurmountable pain that it is.

Seriously, I urge you to look into SGML and to explore what a weird behemoth it is, and to then realize that SGML is what XML grew out of.

Unfortunately, XML was so bad that the developer community suffered some form of whiplash from it, and promptly decided to run into the opposite direction: JSON, which--superficially at least--seemed to be the simple and easy answer to the problems XML was causing.

However, I don't think that XML's problems were in its ideas, but that JSON is taking away too much that had only been perceived as bad, because it came coupled to such a flawed implementation overall.

And now we have efforts like JSON Schema, which emerge out of the realization that writing the same typecheckers over and over again for nearly every use case is tedious at best, and error-prone and unsafe at worst.

So maybe we will get our conveniently typed and namespaced semi-structured data in the end, but I blame XML that we had to take a detour over vanilla JSON to eventually get there.

"conveniently typed and namespaced semi-structured data in the end" - I don't think that thing will be much more simple than XML - it needs to cover Unicode, data types, namespaces, modularity and you end up with XML-level of complexity. I know wheel gets reinvented a lot in software, but with data formats you also need tools, adoption, compatibility - XML wins here

It might not be very simple, but I certainly hope it does not necessarily imply SGML levels of cruft. The things you have covered don't need any of that cruft. You are right that adoption is a major hurdle for any new solution, if it's even attainable, but that's pretty much my point. I'm sad that XML came to reach critical adoption for semi-structured data, and not something else.

I think the reason for this increasing complexity comes from efforts to be satisfy every single use case. When everybody starts pitching in in the creation of the standards with their weird corporate use cases and actual specification writers try to satisfy each and every one of them. There is no reason schema specification has to be very complex. Instead, it can be made open for extension but be very concise and with clear boundaries itself.

XML is really great for its intended problem domain. Try to represent XHTML or DOCBOOK or similar rich-document formats as JSON and it will be a disaster.

But for structured data you don't need the verbosity and extra baggage of XML, JSON is simply a cleaner solution.

Problem is, people are looking for one-size-fits-all solution, but no format will be optimal for all use cases.

XML is a passable all-round format though, even if it is not always optimal.

Interesting. I was going to email the link to some co-workers that work with XML frequently. I wrote a nice little email with the link, then decided to put the text of the billion laughs attack into the email. Select the full XML in the browser, change to the email client and past, and the client immediately becomes unresponsive. I open up "Activity Monitor" and the clients memory consumption is rising precipitously, and was at 19gb when I killed it. Microsoft Outlook 2016 for Mac. I was really surprised that an email client would try to interpret the XML rather than just displaying it as text.

The same thing happened in JetBrains IDEs until about a year ago. I remember having to save my XML bomb unit test in a *.txt file to avoid freezing my IDE.

Maybe it was trying to be helpful - detected you were pasting XML and tried to pretty-print / colorize it.

For that a parser without any intepretation would be sufficient.

> Simple structure, a little too verbose

The "too verbose" bit is overly broad cargo-cultism.

XML has valid, efficient applications. A prominent one: it's a more concise serialization format than JSON (the supposed alternative) for describing self-similar typed hierarchies, e.g. scene graphs or other UI trees. (see HTML, XAML, VRML, kind-of JSX.)

consider:

  <div>
    <span>Hello world</span>
  <div>

vs:

  {
    nodeType: "div",  
    children: [
      {
        nodeType: "span", 
        children: [
          {
            nodeType: "text", 
            value: "Hello world" 
          } 
        ] 
      } 
    ] 
  }

It's hard to take the rest of the article seriously when it starts with that unnecessary (and imprecise) jab at the technology it purports to be educating about.

There are more concise ways to use JSON. For example:

["div", ["span", "Hello world"]]

You can also add attributes:

["div", {"id": 123}, ["span", "Hello world"]]

Parsing is a bit trickier and the format is less obviously extensible, but in general, JSON arrays are more concise than JSON objects since you can leave out the field names.

Just wanted to add that this use might not be common in JSON but is extremely common in S-Expressions, which predate XML by 40 years or so, and are probably a better XML replacement than JSON (if you only regard technical details and ignore popularity and library/language support)

When people say this I wonder how much lisp readers are really standardized. (Consider reader macros.) It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate, even if they're both lisp variants.

I guess that's the problem edn [0] was trying to solve, but it doesn't have wide enough adoption.

[0] https://github.com/edn-format/edn

Common Lisp is reasonably standardized -- that's the whole point of Common Lisp, though it is hardly dominant. Among general Lisps and Schemes, readers are not standardized enough to say "kill XML, we'll just have S-Expr" (though I'm not sure what percentage of XML parsers out there follow the XML spec to the letter either).

> It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate, even if they're both lisp variants.

Scheme has a decent, albeit small, standard [0].

SXML [1] is also standardized, as part of that process, which makes writing it nice and predictable. So, for the most part, SXML should work the same between implementations, but, if it doesn't, all you need to construct an SXML object is: quote or quasiquote and unquote.

SXML feels far more like a template language than a serialization format.

---

But the wider question:

> It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate

For the most part, they should be.

But!

S-Expressions are a terribly inefficient structure in memory, or rather, can be. How you optimise that can have some impact on what the reader accepts or rejects, or how it compiles into memory.

Singly and doubly linked lists, vectors, arrays. S-Expressions can be all under the hood, or a mix.

Some parsers reject variadic s-expressions, others accept them happily, but others have a limited recursion depth, so technically valid s-expressions get rejected.

However, for the most part they're equal.

---

[0] http://www.schemers.org/Documents/Standards/

[1] http://okmij.org/ftp/Scheme/SXML.html

A bit off topic but I wrote a very small JS library that uses this exact format 6-7 years ago. It transforms such an object to a DOM tree. This is nice to see somebody mention this format, this kind of validates it. So, thank you!

It also accepts things like ["div#123.class-name-1 class-name-2", ["span", "Hello world"]].

You can keep a reference of a node in a Javascript object if needed:

  let refs = {};
  
  let div = jso2dom(
      ["div",
          ["span", {"#":"sp"}, "Hello world"]
      ],
      refs
  );
  
  console.log(refs.sp); // <span> Hello World </span>

I've found it very convenient so far and still use it today. This is simple, prodigiously stupid and works in vanilla JS, so this works for me for the time being.

Parsing may be complex but in my case, this is done by the Javascript engine, so I'm not affected by this complexity.

XML is not a serialization format. It's a structured document format. For, you know, human text and stuff.

When used as intended it is wonderful.

Sites that hijack the "back" button -- be cautious.

…this is a Medium article.

And it still hijacks the back button, and therefore shouldn't be read.

If you're handling XML in Python, defusedxml (https://pypi.python.org/pypi/defusedxml) is a nicely packaged set of XML parser configurations that mitigate attacks in untrusted XML.

Reply on news.ycombinator.com