
XML fever (2008) - wtbob
http://queue.acm.org/detail.cfm?id=1466454
======
agentgt
Now in 2015 we have XML prejudice and aversion where people trash XML as the
worse possible format. As with many things it has its strength and weaknesses
a couple of them being that a parser exists for almost all programming
languages and the syntax of XML is probably the most widely understood (given
so many people know HTML). And while XML is complicated there are far more
complicated formats (YAML).

What we have today is format creation fever. Particularly in configuration
languages. Hucon, TOML, YAML, JSON, sort of JSON formats (HJSON or whatever it
is).

~~~
legulere
It's just because XML is a bad choice. It's a standard for creating markup
languages, but use in HTML failed because it's more verbose and doesn't cope
at all with user errors.

For data serialisation it's just insane. The only reason to use XML to
serialize your non markup data is that it's a web technology and you have
parsers everywhere. Mapping data back and forward between your data structures
and the XML representation is a huge pain in the ass, as there's no natural
mapping. For some formats like SVG you basically have to keep data as a DOM in
your program.

> And while XML is complicated there are far more complicated formats (YAML).

While the Syntax of YAML certainly is more complicated, totally I would say
that it's less complicated without all the XPath, Namespaces etc. you
additionally need. YAML maps fairly direct to data structures of programs and
the complexity is there to get human readability and edit ability. Something
XML doesn't have when used for general data.

> TOML

Is basically just a specification of the largely unspecified INI format, which
is older than XML. This is just a format for human editable configuration
files, for which we have experience that XML really really sucks.

> JSON

Very simple data format that maps directly to data structures of all common
programming languages. The fact that JSON beat XML where XML is at home, in
the web shows pretty clearly that JSON is the better format for data
serialisation.

TL;DR: Use the correct format for the use case. XML is for markup, not
serialisation. JSON is for serialisation, YAML is a better readable JSON e.g.
if you mainly use the data for debugging, INI(/toml) is for configuration
files.

~~~
agentgt
While I think we are on the same page (I did say XML has strength and
weaknesses) I think XML is undervalued for a configuration language
particularly if the configuration language is to be modified by another
application or script.

The reason a markup language like XML is actually sort of useful for a
configuration is that spacing and comments can be preserved on modification.
That is if I modify the XML manually and then modify it with a script
(assuming the script is written correctly) I can preserve my formatting and my
comments. As far as I understand such is not the case with many formats (I
suppose YAML would be the exception albeit I'm not sure if it preserves white
space other than the required whitespace).

I have actually had this use come up. I had 20 or so Maven POM files that I
had to modify/refactor. It was fairly easy to do because it was XML all while
preserving the formatting and comments.

With the exception of massively complex configuration (aka Ansible) I really
don't think most users (particularly non-techy) care that XML is slightly more
verbose than YAML. Particularly since configuration is not modified that often
and again its like HTML (although HTML is a failure technology wise it is
ubiquitous).

As for serialization... XML is bad... I can't come up with any devils
advocation for that.

------
arethuza
"one of the most troubling XML problems that is often experienced when
encountering schemas generated from UML models"

To be fair I think pretty much _any_ kind of output generated from a UML model
typically has serious problems (code, databases schemas, XSDs, documentation).

------
ctstover
I'm sure others who have been around longer remember other examples, but in my
life I have never before or since witnessed a media blitz for a "technical"
standard as the coming out party for XML in the '90s. Almost overnight the
book shelves, magazines (yes those were both things back then), and even TV
news proclaimed the dawn of the new age. A wave incoherent mass insanity swept
the industry with the promise that this sometimes white space sensitive text
data format with all the deliberate under and over specifications that are
hallmark traits of design by committee was literally going to solve every
problem in software engineering, enterprise IT, and of course investing in the
dot com dumpster fire (pre first collapse). The emperor never had any clothes.
Disk space, network capacity, cpu time, sanity, dignity - mattered not. No
problem could not be solved better with XML. Dissension was heretical.

Any one else remember that?

~~~
dmichulke
To this date I feel frustrated when I have to deal with a few pages of XML
that could easily be a few lines of json. Then again, enterprises love it, so
I can't complain too often or loud.

Still, I often refer to it as XMHell and if you speak it fast enough, only the
truly wise will understand and acknowledge it with a smile and a nod.

~~~
conorgdaly
"a few pages of XML that could easily be a few lines of json"

There is no sane way that you could represent "pages of XML" in "a few lines
of JSON". Maybe the point you're trying to make is that you need just a
handful of key:value pairs but whatever generates your config sees fit to do
incredibly deep nesting...but that would be an issue with your application,
not XML.

~~~
dmichulke
_> There is no sane way that you could represent_

I think you're wrong, namely because of arrays. Can you tell me how you'd
represent [1, 2, 3, 4] in xml?

If you think this example is contrived, please compare the dependency sections
of a clojure project.clj vs that of a Java pom.xml

------
PaulHoule
"No connection between RDF and XML" is definitely not true.

(1) RDF uses the XSD types for literals, and (2) you can turn an XML document
very directly into an RDF graph with interconnected nodes.

Once you have done that you can go to "plain" RDF with simple production rules
instead of insanely complex XSLT. That is, 250 lines of XSLT goes down to 10
lines worth of rules.

------
georgeecollins
I feel like there is a similar condition, JSON fever.

~~~
netheril96
I am a JSON apologetic that uses JSON for _all_ serialization except when
performance is critical. I am all ears for why I am wrong on this.

~~~
kyberias
No-one said you're wrong. Maybe that's one of the symptoms of said fever. ;)

------
iamthepieman
I spent several years working with the Marklogic[0] document database before
NoSQL was cool and before I had even heard the term. It was incredibly freeing
working with arbitrary XML documents and fragments. As a benefit we were able
to transform data into HTML markup with a simple XSLT transformation.

You could create multiple views on the same data by just adding some logic to
your XSLT or creating a new XSLT

Queries are(or were at least, it's been many years) built in Xquery which is a
simple, functional language that I found much easier to grok than SQL.

Since XML is just a tree and both XSLT and Xquery work on the trees quite
well, advanced searching, sorting and relationship graphs came almost for
free. I would gladly work with that stack, or something like it, again.

[http://www.marklogic.com/](http://www.marklogic.com/)

~~~
EiZei
> a simple XSLT transformation.

You don't see those words together too often.

------
vinceguidry
"XML is like violence. If it isn't solving your problems, then you aren't
using enough of it."

------
rrmm
I inherited an application from a person who was apparently taken with XML.
The app's data and output was kept in his own home-brewed XML format with hand
written output and parser functions.

His understanding of XML was as follows: Put whatever you want between '<'
'>'. It certainly beats reading the w3c docs. Needless to say, I rewrote the
application from scratch.

~~~
krylon
> His understanding of XML was as follows: Put whatever you want between '<'
> '>'.

Well, in all fairness, somebody with _that_ attitude would give any
serialization/data format a bad name. While I am not a fan of XML, you cannot
blame that one on it.

------
supahfly_remix
XML can have a defined schema to validate data against. Does JSON have
anything similarly defined as part of the language? It seems like an
afterthought. Does anyone use it in practice?

~~~
arethuza
JSON Schema seems to work pretty well - I've used it in Python applications:

[http://json-schema.org/](http://json-schema.org/)

I don't think there are any fancy graphical editors as there are for XSDs -
but that's probably not a bad thing as I suspect if things are getting so
complex that a graphical editor makes sense then you've probably allowed
things to get too complex anyway.

------
jdnier
If you're looking to describe document structure in a markup language,
especially where mixed content is involved (think think running text, not
database results), XML is great.

