Hacker News Reader

Comment by tootie | Hacker News Reader

We've spent like 10 years trying to fill in gaps left when we all decided to hate XML. JSON is great as a lightweight DIF between trusted partners. If you care about maintenance and safety, XML with XSD is rock solid.

View on HN

I don't know, XML is awfully verbose and the schemas are even more verbose. I've lost track of how many "XML" configuration files that looked like this:

   <parameter>
     <name>ApplicationName</name>
     <value>WhizBang</value>
   </parameter>
   ...

So that they could pass schema validation and still have some hope of extensibility.

A few weeks ago, I had about 100 config files (tomcat context.xml) which all needed fixes for common misconfigurations - if they had the misconfigurations in the first place The kind of problem that is just a little bit too hard for search and replace. It was really easy with xslt. The result had all comments preserved. I choose to reformat the files, but keeping whitespace was an option too. Now tell me if you can do that with json,yaml,toml. Most parses simply forget about the comments to begin with.

In the same way, if we receive a data transfer in XML and there is a schema, simple validation catches a lot of problems quickly. You'd be surprised how many times a company gives you a schema and then sends you xml which doesn't validate. In JSON, you have to write a program to get even basic validation.

Don't get me wrong: XML has problems, some inherited from html/sgml (entities!), and even more after serious abuse by consultants, archicture astronauts and enterprise vendors (SOAP! namespace overuse! 10 XML parsers in 1 app!). But it was also miles better than what came before and I feel the XML hatred pendulum has swung too far.

Today, JSON is in vogue, and I've seen enough IT to not swim against the tide. It is a reasonable solution for problems caused by XML abuse. Besides, there is value in going with the majority,even if it only fixes 80% of your problem. But I can only weep for the miserable date, numeric and comment support, and their endless stream of incompatible workarounds.

For your parameter example: You can't both strictly validate and have full freedom at the same time. Something has to give a bit. Some less horrible alternatives I've seen:

  <parameter name="X" value="Y"/>

  <subsystem name1="value1" name2=value2 ... /> , add newline for each  attribute

  <name>value</name>

What problems wrt entities does XML have that it has inherited from SGML and HTML? Do you mean entity expansion attacks such as million laughs? HTML has only character rather than general entity references, and SGML has had the ENTLVL capacity to bound entity reference nesting since the year 1986.

Edit: XML is just a proper subset of SGML by definition, hence it didn't introduce a single thing that wasn't there before. It only introduced XML-style empty elements and DTD-less markup, and SGML was extended in lockstep with XML to support these as well

I'd consider user definable entities a problem, as you can't read a file without knowing the DTD. Million laughs is just a very ugly bonus.

XML is more than the part inherited from SGML, it's also the XML culture surrounding it. Namespaces are an example of something that created an XML dialect. And of course SOAP, which actually needs the WS-I standard to explain what parts of the WS-* standards to use or ignore, and how to interprete them. And even then 2 WS-I stacks will rarely interop without trouble. Lets not blame SGML for that monstrosity

What's wrong with namespaces? These are simply globally unique identifiers that allow us to define and use our own globally unique names and make them passably human-readable. That is:

  <a:log /><b:log /><c:log />

can mean a math function, a text file that records what's happening, and a cut-off trunk of a tree and there will be no confusion whatsoever.

(I really don't get how SOAP is relevant here.)

I would definitely use RelaxNG for specifying schemas instead of XSD - it's simpler both to read and write in every case I've tried, and the resulting schema is smaller as well, often by a lot.

  <element name="addressBook">
    <zeroOrMore>
      <element name="card">
        <attribute name="name">
          <text/>
        </attribute>
        <attribute name="email">
          <text/>
        </attribute>
      </element>
    </zeroOrMore>
  </element>

http://www.relaxng.org/tutorial-20011203.html

Plus there's a non-XML "compressed" version as well:

  element addressBook {
    element card {
      element name { text },
      element email { text }
    }+
  }

But I agree that XML like you posted is nasty, it's no harder to write

  <parameter name="ApplicationName">WhizBang</parameter>

instead if you need generic parameters, or

  <ApplicationName>WhizBang</ApplicationName>

if not.

Why not just

<parameter name="ApplicationName" value="WhizBang"/> ?

That's the age-old question, isn't it?

Your option is better, but XML is very (maybe too) flexible and is bound to be made a mess of.

I've seen some pretty messed up schemas in JSON and YAML, too.

That's still worse than <ApplicationName>WhizBang</ApplicationName>. Or

    ApplicationName=WhizBang

XML is verbose, and overcomplicated. But most purported replacements trimmed too much.

To be quite honest I dislike using XML for human editable configuration files. Variations on Microsoft's .ini files (such as TOML) seem to work best for that, IMHO.

We use .ini files for all of our settings in our products, and they work great most of the time. The only weirdness creeps in when you try to store things with embedded CRLFs and need to escape/unescape them (not a big deal), and storing lists of things is a little difficult.

JSON is great in terms of flexibility, but .INI files are really easy to read because everything is on the left side of the screen/window at all times.

XML is in that odd middle-ground where it's usually human-readable, but also a huge pain in the ass to write. It's great at what it was intended for, as a data interchange format.

For a general-purpose human-writable structured data format, I guess the ugly nonstandard hack that is "JSON with comments" is probably good. It's certainly faster to parse than YAML.

XML wasn't intended as data interchange format, but for replacing SGML as serialization and markup meta-language on the Web (eg. for XHTML, SVG, MathML). It can't be said often enough that markup languages are for authoring and delivering semistructured text data, not for general-purpose data serialization. As in, editing plain text files and have your text treated as content unless marked up with markup and annotated with metadata attributes. Though this is much more pronounced in SGML which also contains the features for authoring (as opposed to delivery) omitted from XML such as tag omission/inference, custom Wiki syntaxes, and other short forms.

Well, what is the purpose of markup languages? Isn't the sole purpose of markup is to be able to process the marked-up content with a computer? Why would you add markup to your favorite verse if it wasn't to somehow feed it to machine for some purpose (analyze, typeset, etc.)?

So when we have text with markup the text part is meant to be there for humans and the markup part is solely for computers. Now let's remove all text; now there's no content for humans at all, only for computers. How is this different from general-purpose data serialization?

(Some of the samples you give, like SVG, may not have any text content at all; it's basically a drawing language.)

Given that XML ecosystem has quite a few tools (e.g. several type description languages or a declarative data transformation language just to name a few) it's a very good general-purpose data serialization format.

I've managed to teach non-programmers to successfully edit YAML files without too much trouble, but most non-programmers have a really hard time consistently producing valid JSON by hand.

As much as there is a lot to not like about YAML, it is the easiest one for humans to consistently write in my experience.

But why should they have to do it by hand?

We don't judge Excel and Librecalc by how easy it is to open their files and produce valid spreadsheets without good tooling.

If they're working with structured data, why can't they use tools/editors which work with the structure, reveal it, and enforce it?

> It's great at what it was intended for, as a data interchange format.

XML's incredible verbosity is a problem for computers too. I've spent time performance-tuning message parsing code that had no good reason to be slow except that our use of XML bloated the data and decoding time by an order of magnitude or more compared to a binary protocol with a schema.

In my experience if you are using XML as a data interchange format and it's slow it's probably because you are using a DOM parser instead of a SAX parser. DOM parsers build a tree that is best used describing a marked up document and much less useful for describing a data structure you might want to serialize or deserialize.

I've gotten incredible speedups just by switching to SAX parsing in those cases.

My biggest complaint with JSON is the lack of support for comments. For that reason, it's hard to take it seriously for human-maintained configurations.

Comments and trailing commas. If those two features were added, I would use JSON for configuring everything. Naked keys would be a distant third. My conclusion is to use TOML or the protocol buffer text format.

I've been slowly ripping out YAML support and converting configurations to TOML.

Not just trailing commas, but the need for commas at all when there is a newline right next to it has been a source of many stupid issues for me when less knowledgeable/experienced people edit json based conf files.

Then there is floats without a leading zero. Missing colon after the key. And yea, naked keys. The need to wrap the entire file in { } or [ ] is just icing.

Honestly I feel the most bare simple conf format of [first-word] [rest-of-line] is enough for many programs that end up using but never taking advantage of more powerful formats.

> but the need for commas at all when there is a newline right next to it

JSON is often minified though - you're going to need something to use as a delimiter

Newline and comma are both 1 byte. You could specify that either is acceptable.

Actually, I think you could leave out the delimiter altogether and still be syntactically unambiguous, since quotes are required around keys:

    "key1":"value1""key2":2.75"key3":true"key4":"whatever"

though this looks terrible and there's probably some edge case I've forgotten. (Also it misses the point of JSON in that it's no longer valid JS. I don't know whether that's important anymore since you should be calling JSON.parse() not eval() anyway.)

> you should be calling JSON.parse() not eval()

The one major reason I could see to use "JSON" as a conf file is in trusted node.js apps because you can then easily embed functions and logic in them if you need more advanced/customizable configurations. And you can do it with full syntax highlighting in your editor. And comments, and trailing commas, and naked keys.

Of course this is no longer JSON, it's straight up Javascript config files. But it has come in handy a few times when I want to override standard behavior on a per config basis, and most of the file is still just plain key: val

A newline character is just as minimal as any other ASCII delimiter.

I would hope minified JSON is not being used for conf files.

I got hit by lack of comment support in go-yaml recently.

https://github.com/go-yaml/yaml/issues/132

"comment": "blah" is one hack.

it's a shame json doesn't support them though. oh well. would be nice to restart the universe and get all this right next time. :-)

I get a lot of flak for this, but there are definitely times I miss XML for certain things and find it way easier to work with than JSON or YAML. I definitely understand some of the backlash against XML that happened a decade or so ago and definitely don't want to return to the days of half of a Java application being XML code.

I think JSON is more efficient to write, but XML often ends up being more efficient to read due to comments and the fact that XML tags often give you better context. I think most programmers (myself included) tend to heavily optimize towards writability when we should think about readability a little more.

An example of this is ElasticSearch, where your queries are in JSON and often end up tons of levels deep - it is super easy to get lost in a sea of closing brackets, whereas XML would let you add comments in and the fact that closing tags have names in them would give you better context about what you were doing.

Well, if you go deeper down the rabbit hole, XML was a complete and utter waste of time. This problem was solved in the 60's with S-Expressions.

> This problem was solved in the 60's with S-Expressions.

Not so much. Sexps don't provide a place hang "extra" information. It's been a pain point. While some lisps allowed decorating runtime things (eg objects with attributes, and symbols with property lists), their printed/readable representations were implementation dependent.

There's also a widespread misconception that Scheme is easy to parse. Numbers and all. It's actually very hard to get right. Real scheme parsers are quite large and hairy.

> XML was a complete and utter waste of time.

While XML was ghastly, there was an unmet need. There still is.

Yeah... I'm a diehard Common Lisp user, and when I saw YAML+go-template used for Kubernetes Helm templates, with some extra hacks to take care of indentation shifts... I felt almost physical pain.

XML has many of the same security problems that YAML does, and even some additional ones.

XML isn't bad, but everyone went crazy and decided to use it for everything which didn't work out well. Then the backlash happened.

Safety? Sounds like rosy retrospection to me. We're still dealing with XML vulnerabilities.

Safety? The OWASP Top 10 doesn't feature a JSON security issue.

https://www.owasp.org/index.php/Top_10-2017_A4-XML_External_...

DTD and SOAP are both awful.

Especially when technologies like E4X came out to make writing and reading XML in JS so much easier. Although I don't miss SOAP at all.

What is a DIF?

"data interchange format"

Data Interchange Format

Reply on news.ycombinator.com