Hacker News Reader

Comment by bane | Hacker News Reader

My "favorite" XML formats are the one that are just some kind of weird meta-format and don't really use any of the XML features:

   <format>
      <record id="1">
         <field name="id" value="1"/>
         <field name="name" value="abc">blah blah</field>
         <field name="attribute">this is the attribute value</field>
         <field name="end_of_record" value="True"/>
      </record>
      <record id="2">
      ...
      </record>
   </format>

And yes, these types of abominations are everywhere.

The only way to avoid being called a Bozo when producing XML is to either

a) ensure that humans never had to see this craziness

b) don't use XML

XML as a config file format, in particular, is probably one of the worst ideas in computing.

View on HN

Here is an event from a popular sports data provider's XML format, for your delectation:

    <Event id="524717408" event_id="1" type_id="34" period_id="16" min="0" sec="0" team_id="20" outcome="1" x="0.0" y="0.0" timestamp="2014-11-30T12:29:59.446" last_modified="2014-11-30T13:24:03">
      <Q id="2045368832" qualifier_id="59" value="23, 2, 21, 12, 6, 17, 8, 4, 19, 11, 10, 1, 3, 5, 7, 24, 28, 33" />
      <Q id="1068483434" qualifier_id="227" value="0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0" />
      <Q id="840260679" qualifier_id="197" value="425" />
      <Q id="1586850783" qualifier_id="30" value="40383, 57328, 40146, 54756, 38580, 55605, 17339, 42774, 17784, 62399, 110979, 3673, 80447, 84395, 20452, 49596, 153366, 169359" />
      <Q id="340265857" qualifier_id="44" value="1, 2, 2, 3, 2, 2, 3, 3, 4, 4, 4, 5, 5, 5, 5, 5, 5, 5" />
      <Q id="328261435" qualifier_id="194" value="38580" />
      <Q id="1426777221" qualifier_id="130" value="4" />
      <Q id="293008363" qualifier_id="131" value="1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 0, 0, 0, 0, 0, 0, 0" />
    </Event>

XML and CSV, together at last.

Reminds me of the beautiful paths in svg:

     <path
       id="path4136"
       d="m 141.42136,428.08793 c 5.24568,-16.5136 15.9393,-31.24659 30.01423,-41.35166 14.07492,-10.10508 31.45369,-15.52663 48.77766,-15.21688 13.79473,0.24664 27.51957,4.08979 39.39595,11.11168 11.2946,6.67792 20.92213,16.25825 27.27185,27.74057 6.34973,11.48232 9.35256,24.85978 8.08349,37.91934 -0.97817,10.06598 -4.47673,19.87936 -10.10152,28.28427 -7.66405,11.4521 -18.89192,19.94346 -29.67188,28.52721 -10.77995,8.58374 -21.59293,17.81326 -27.90682,30.06164 -5.96111,11.56401 -7.38898,25.49638 -3.38484,37.87491 4.00414,12.37853 13.52214,22.96957 25.6082,27.78501 6.7156,2.67569 13.99861,3.58421 21.2132,4.04061 19.62989,1.24181 39.40632,-0.70279 58.58885,-5.05077 14.7604,-3.34565 29.1633,-8.0984 43.43656,-13.13198 20.00787,-7.05594 40.67497,-15.26376 54.54824,-31.31473 4.77196,-5.52102 8.57644,-11.80437 12.12183,-18.18274 19.76105,-35.55128 32.20013,-75.50916 33.33503,-116.16755 0.65168,-23.34676 -2.46779,-46.99293 -11.11168,-68.69037 -5.01987,-12.60061 -11.95904,-24.5794 -21.47642,-34.24345 -9.51738,-9.66404 -21.73721,-16.92383 -35.09212,-19.29463 -2.34449,-0.4162 -4.71259,-0.68237 -7.07107,-1.01016 -18.71745,-2.6014 -36.77133,-9.07291 -55.55839,-11.11167 -15.41222,-1.67253 -30.96773,-0.32564 -46.46701,0 -8.75302,0.1839 -17.50911,0.0413 -26.26397,0 -19.79058,-0.0933 -39.767,0.35345 -59.02055,4.93345 -19.25355,4.58001 -37.93007,13.61662 -51.08608,28.40158 -10.37036,11.65439 -16.79892,26.19465 -23.23351,40.4061 -3.97708,8.78379 -8.01783,17.53876 -12.12183,26.26397"
       style="opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:2;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />

The biggest advantage of XML was the detailed schema validation. Having a uniform and flexible way to both generate data structures and ensure that their contents was valid before ever attempting to process them was handy.

XML had a lot of warts but most of its strengths are still seeking passable implementations in JSON. Protocol Buffers is probably the closest thing to being standard in that area for schemas and generation. The number of JavaScript templating options out there are trying to fill the XSLT gap.

Yeah, I acknowledge that bit.

But I also think the various schema definition languages (DFDs, XSD, whatever) turned out to be either not expressive enough (DFDs), or a complete PIA (XSD) and in the end, they weren't used very often.

Still, it's nice to have them when you need them and when they aren't there it hurts.

I'll definitely agree with that. I remember using some Java desktop GUI to generate XSD's rather than typing all that stuff out.

Relax NG validation is very good; it's more expressive than XSD and it has both XML and non-XML forms and looks very nice.

It's also that it's extensible (primarily because of namespaces) - you can mix and match schemas so long as one of them uses xs:any. This brings up another way to avoid being called a bozo: namespace your XML. You're throwing a major advantage away if you don't, and if you don't need/understand that advantage then you're better off using a different serialization format.

I don't necessarily disagree, except for the last point. I've rarely (never?) encountered XML used as a config file format where users were expected or encouraged to edit that config file directly vs. using other tools or APIs to touch the file.

In those cases, I would rather have XML config files than undocumented binary blobs as config files. When I see an XML config file, I feel a little relief that it's not a binary blob rather than disappointment that it's not freeform text, because I assume that freeform text must've been off the table for whatever reason (which, depending on what the config file is for, can be a totally rational and reasonable thing to do).

I don't work in specialties where XML has a ton of visibility though- maybe there are lots of projects out there that I don't use in which people are required to hand-edit XML config files, as opposed to "it's in XML, so you could edit it directly, but really no one should be modifying the file with a text editor unless the preferred indirect mechanism isn't an option in some specific case".

>In those cases, I would rather have XML config files than undocumented binary blobs as config files.

False dichotomy.

Better than XML and binary blobs:

* JSON (assuming everyone knows what this is)

* YAML [0]

* Lua tables (if you're already using Lua as a scripting language; Lua started out as a configuration language after all)

* INF format [1] (not my favorite, but pretty easy to parse and much better for humans to read than XML)

* Any of the above compressed with a gzip compatible compression (if size matters, though it rarely does these days)

Even Protocol Buffers [2] are better than XML, though at that point it becomes a "documented binary blob". But as long as the spec is shared, the format can easily be read by just about any programming language.

[0] https://en.wikipedia.org/wiki/YAML

[1] https://en.wikipedia.org/wiki/INF_file

[2] https://en.wikipedia.org/wiki/Protocol_Buffers

GP is obviously not stupid enough to think that XML and binary are the only options. Their whole point seemed to be that they've seen enough binary blobs in practice that even XML was a welcome step up.

> JSON (assuming everyone knows what this is)

The new .net uses json, it's awful. No comments allowed and it get's pretty unreadable when you have nested configuration elements.

I seriously think the lack of comments is a deal breaker for JSON config files for me. At least with what I'm doing now. I find myself changing configs a ton, and I love being able to simply change which blocks are commented to get what I want, without having to dig anywhere.

I agree...and I found a Gulp plugin that lets me pre-strip comments from my JSON files as part of the build process.

So I use JSON-with-comments, but the app only sees the stripped files.

VSCode uses comments for every line in its settings.json file.

I guess they figured it may not be correct JSON, but since they aren't sending those particular JSON files anywhere it doesn't matter?

JSON5 [1] is an extension to JSON that allows comments, multi line strings, additional commas at the ends of lists, and more. It has become my preferred config file format.

[1] http://json5.org/

And instead of Protobufs, Cap'n Proto [1], which was started by one of the principal author behind Protobufs, to fix all the flaws in Protobufs.

[1] https://capnproto.org/

You can use Protocol Buffers for configs without having to serialize them in its binary format. Protocol Buffers has always had its own text format [0] and now a JSON mapping [1] as well.

The proto text format is actually more flexible and less verbose than JSON since it does not require the outer enclosing set of braces and quotes around all the keys and has support for comments.

Here are a couple of examples of config files using the Protocol Buffers text format:

* Bazel CROSSTOOL: https://github.com/bazelbuild/bazel/blob/master/tools/cpp/CR...

* SyntaxNet: https://github.com/tensorflow/models/blob/master/syntaxnet/s...

[0] https://developers.google.com/protocol-buffers/docs/overview...

[1] https://developers.google.com/protocol-buffers/docs/proto3#j...

I've always considered YAML to be far too complicated. There are many overlapping/redundant syntax rules for doing the same thing, lots of ways to mess up parsing, etc.

True, but if you turn those "features" off and swap out implicit typing for explicit typing it becomes a much simpler language.

This is what I ended up doing:

https://github.com/crdoconnor/strictyaml

I am missing a config file format / parser&generator lib that preserves every comment and format (empty lines, etc.) after a read/write cycle.

I've written that for Lua files. And I've seen it for XML, to be fair.

I'd say TOML [0] is the best because it can be a very simple key=value structure, but also supports very detailed, nested structures. It has a 1-to-1 correspondence with JSON, but is more friendly for configuration (comments are a huge help!)

[0]: https://github.com/toml-lang/toml

I've mostly come across XML config files that are meant to be edited by humans in various programs that use some kind of Java framework as the back-end.

I don't Java much, so I'd be hard pressed to remember the various framework names (Spring maybe?) but I remember at one point writing a Python script to de-XML the config files into something that was just a bunch of key=values, then another Python script to convert it back to the required XML. IIR on that project, the handful of config options that needed to be tweaked were spread across a dozen or so different XML files.

If the framework could have just read a .txt file with key=values in it, config changes would have gone from 10 minutes to 30 seconds. I eventually just wrote a python thing that auto-deployed and configured the entire stack after asking you a couple questions.

It was absurd.

I believe Android development does (used to?) require lots of hand XML editing. Most of which just drives a Java code generator. I guess the tooling is better these days, but it was enough to drive me away.

Spring was certainly a very XML focused framework.

However it has had for a long time ways of using property files in conjunction with XML, while you would still need the XML to define your dependencies, you could have a simple property file for runtime configuration.

Thankfully in newer releases and with spring-boot you can avoid XML entirely.

Config files are usually plain key-value pairs and, of course, using a whole eXtensible Markup Language for them is kind of overkill. But if your config files are more complex, say, you need a Makefile-like stuff, then XML is more than appropriate.

>> I've rarely (never?) encountered XML used as a config file format where users were expected or encouraged to edit that config file directly

I think it's more like, it's a text format (no matter what the op recommends) so it can be edited. If you don't want anyone editing your configuration you don't store it in a text file, right?

Not to mention stuff like pom files that are explicitly meant to be edited by hand. Gods, why?

There are plenty, especially in the Java and .NET worlds. To name a few:

* Ant/Ivy * Maven * MSBuild * NuGet package configs

I'm sure you will also love JSONx: http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com....

There....that's a perfect example. Thank you.

Well, if you have to store arbitrary, opaque JS object in XML document, it is much better way than JSON in CDATA

You're going to "love" this little guy: http://txti.es/barry/xml

Only slightly better is the JSON counterpart: http://txti.es/barry/json

Microsoft pretty much standardised on XML all through the early .NET framework - app.config and web.config, plus most project files are XML files, and defining your own configuration (past simple key/values) is very tricky and error-prone.

How would you write that example while taking advantage of the XML features you're talking about?

I think what you might be asking is "what would more idiomatic XML look like?" And that's a fair question for people who haven't spent lots of time working with XML.

First off, I think attributes are evil. In theory, they're good, but nobody knows how to use them, so they shouldn't ever be part of your XML. They're simply elements with cardinality of 1.

The format would probably be better as:

   <format>
      <record>
         <id>1</id>
         <name>
            abc
            <comment>blah blah</comment>
         </name>
         <attribute>this is the attribute value</attribute>
      </record>
      <record>
      ...
      </record>
   </format>

This is a completely valid XML language, is much more clearer, less verbose, doesn't overload element names, doesn't abuse attributes, etc. etc.

One important thing that most people don't get about XML is that XML is a specification for describing data-interchange formats. XML isn't a format, or a language. The result of following the XML spec is an "XML format".

If somebody asks what format some data format is in, it's more appropriate to say "it's in an XML" rather than "it's in XML".

Well this reduces to something like:

    <abc>
      blah blah
      <attribute>this is the attribute value</field>
    </abc>

The point is not to write a flexible meta-format for expressing arbitrary objects, because XML is already that. Each specific thing you want to express should have its own specific format. That way you can actually use the validation features too.

Reply on news.ycombinator.com