XML is almost always misused

https://www.devever.net/~hl/xml

by mrzool • 7 years ago

201 204 7 years ago

sosuke• 7 years ago

The larger your XML file is the more accurately you're using it. Less " and more <>. I made these mistakes, using XML like a I was writing an HTML doc.

mpweiher4• 7 years ago

Hmm...somewhat disagree with the "correct" way to express a dictionary. I prefer:

   <root>
      <Name>John</Name>
      <City>London</City>
   </root>

Removes one level of indirection, XML already has keys.

progval4• 7 years ago

That's not a good way to express a dictionary because it does not allow arbitrary strings as key names.

It's also not a good example of XML, because XML schemas should have a fixed list of tag names.

mpweiher4• 7 years ago

XML allows arbitrary strings as key names just fine.

sorenjan• 7 years ago

But the starting point in the example was

    <item name="name" value="John" />  
    <item name="city" value="London" />

where the key names are used as attributes, so it wouldn't work with arbitrary key names either, right?

Felk• 7 years ago

Which works if you either expect a dictionary with a predefined set of fields (which isn't really a dictionary then), or parse your xml in a way that handles arbitrary tags. For a generic dictionary the shown approach is still the way to go, if you really want to use XML for that.

mpweiher4• 7 years ago

XML parsers generally allow arbitrary tags.

srott• 7 years ago

you've just invented plist, wonder if it can be validated by a schema..

  <dict> 
        <key>CFBundlePackageType</key>
        <string>FMWK</string>
        <key>CFBundleShortVersionString</key>
        <string>4.8</string>

...

progval4• 7 years ago

No, GP didn't. They use tag names as keys.

But you answer your question, yes this format can be expressed with XML-Schema:

  <xsd:element name="dict">
    <xsd:complexType>
      <xsd:sequence minOccurs="0" maxOccurs="unbounded">
        <xsd:element name="key" type="xsd:string" />
        <xsd:choice>
          <xsd:element name="string" type="xsd:string" />
          <xsd:element name="integer" type="xsd:integer" />
          <!-- etc. -->
        </xsd:choice>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

jimktrains2• 7 years ago

The main issue I see with that is that if it's a true dictionary, then those elements will constantly be different, which is weird.

Now, if we're just encoding a dictionary that's an already an encoding of an object, then yeah, let's just encode the object directly like you are above.

Sharlin2• 7 years ago

This is not a dictionary, it’s a record. Unfortunately this fairly fundamental distinction has been thoroughly muddied by certain languages that want to use associative arrays for everything.

mpweiher4• 7 years ago

Hmm...you seem to be mapping programming language concepts 1:1 to XML. That is a mistake.

benibela5• 7 years ago

That is definitely the best to use with xpath

foolfoolz• 7 years ago

turns out a well specified format that has a lot of parsers available is useful for more than just a markup language. xml is great at data formatting, a little more verbose than alternatives but also a lot more feature rich

kazinator• 7 years ago

The format wasn't well-specified and didn't have a lot of parsers in 1996 though. The parsers came after the decision was made by a lot of people to use a markup language inappropriately for structured data.

CobrastanJorji• 7 years ago

Here are some very frequently occurring examples of bad schema design:

(4 lines, 75 characters)

Here's the right way:

(10 lines, 133 characters)

I have a suspicion as to what went wrong.

SamBam• 7 years ago

"But if the people who made the strange decision to use XML as a data format [...] they might realise that what they're doing is unsuited to it and unergonomic

The author's point is that XML should not be a data format.

zwkrt• 7 years ago

Is there logic to the authors assertion past “that isn’t what XML was intended for”? It is a pretty nice data format if you want wide compatibility and schema integration.

manicdee• 7 years ago

The author’s point is moot. XML is a markup language intended to convey semantics. By its nature it is a data markup language, because the intent is that a particular type of information lives in specific tags.

For humans, this is documents with certain meanings attached. For computers, it’s documents with certain meanings attached.

It’s all data. XML is a data markup language. It’s just that humans call it “semantics” in a “document.”

benibela5• 7 years ago

I really like <root name="John" city="London" />

It easy to query with xpath

It parses the same regardless of the order. With the right way, is <item><key>Name</key><value>John</value></item> the same as <item><value>John</value><key>Name</key></item> ?

commandlinefan4• 7 years ago

Well, I would argue that he's _still_ wrong about the "right" way to represent this: the _right_ way would be: <name>John</name><city>London</city>.

theamk4• 7 years ago

One thing this misses in the "dictionary" example is that tools (like xpath) push you towards "key in attribute" selection. One of the most common operations we do with dictionaries is lookup by known key, and storing the key in attributes makes it much easier.

spiralx5• 7 years ago

"Key in attribute" is the correct way to do it, it's just that his examples are absolutely terrible and make no sense at all. A completely unstructured list of key-value pairs is overkill for any structured data format.

zippergz2• 7 years ago

If a piece of technology is "almost always" misused, is that the fault of the users, or the technology?

dimitar• 7 years ago

Exactly, this is some variant of No true Scotsman

scarygliders3• 7 years ago

If you mean "users" as in "users of the XML format", then it's the fault of developers as 'users' of their applications don't have any choice in the matter.

zippergz2• 7 years ago

I mean "users" exactly the same way "used" was meant in the author's statement. So yes, the developers, who are the people who are using XML.

Gibbon12• 7 years ago

Marketing usually.

alkonaut10• 7 years ago

I’m going to just argue the exact opposite of the article: xml and json are both structured data formats useful for tree like data graphs, such as objects.

Whether that was the intended purpose when xml was designed is irrelevant. It’s what xml is used for in almost every case.

The author also doesn’t suggest what should be used instead to encode structured data, or perhaps more importantly what should have been used to encode graph like things such as map/lists/objects in the 2000’s. Json really hasn’t been an alternative until quite recently (10 years ago?).

In fact reading the article carefully I fail to see the author argue why xml shouldn’t be used as a data format either.

Koshkin3• 7 years ago

Well, XML is a markup language (and is really good at being that) while JSON is not. Sure, XML can be used as a poor man's data storage, as a base for a DSL, etc., but almost always there are better choices.

jeremyjh• 7 years ago

You aren't responding to the comment here, you are just reasserting the article's position. I'd argue there is not another format that is obviously better for every data storage or exchange use case, or that surpasses all of XML's benefits while minimizing all of its downsides. I don't want to look at XML, but I do understand why it is being used.

arkitaip3• 7 years ago

Yet every time I've stumbled upon XML in the past decade or so It's been used as a data format because it's easy to manage and supported by every platform/tool out there. But sure, let's switch over to JSON or use a SQL database because we can't deal with the fact that XML might be better suited for something that it wasn't originally designed for.

alkonaut10• 7 years ago

What are the better choices? And what were the better choices on the major platforms 10 years ago, the choice of which would have not seen every app use xml config files/dls/storage now?

I use csv when applicable. I use protobufs when applicable. But for the typical use case I choose xml for it's some config/dsl/dataset that needs to be human-editable (support comments, for example), more complex structure than csv supports, and preferably not need an external library or a custom parser. Json, Csv, Toml, S-Expressions, protobufs all fail one of more of these requirements. I'm sure there are others but none that don't have at least one drawback I don't want.

A poor man's data storage is exactly what I want!.

ljm• 7 years ago

It doesn’t answer the question, but I do wonder if XML would be an improvement in devops, compared to the current obsession with YAML. For everything except the part where you write it.

Make an xml stylesheet and your kubernetes cluster is instantly documented.

Mikhail_Edoshin6• 7 years ago

Markup is a mix of scalar and structured data (it's a structure discovered or associated with a scalar) and thus it contains everything it needs to express structured data alone: just remove the scalar. E.g.

  <invoice id="123" customer-id="456" date="20199-10-30">
    <item no="1" product-id="789" qty="42" />
  </invoice>

Is this really a poor man's choice? And compared to JSON?! I can see at least the following advantages here:

1. Each element has explicit type name (invoice, item). JSON is "typeless", which simply means the type information travels out of band. And with XML namespaces these type names can be made globally unique, but still stay human readable.

2. Each element is self-contained, the code that produces the <item> doesn't need to know if there was an item before or after it so that it should add a separator. (The dangling comma problem in JSON.)

3. The attribute names are not just arbitrary strings as in JSON, there are strict rules of what can be in the name. They're much more suited for structured data than JSON, where you can name an attribute "foo.bar" and some JSON readers that accept a JSON "path" won't be able to find it.

4. It has less visual noise than JSON because the attributes don't have quotes around them and you don't need to separate elements with a special symbol. Despite the common belief well-written XML is more readable than JSON.

And we haven't event touched things like validation + extended types, references, and transformation of data.

taberiand3• 7 years ago

what should be used instead to encode structured data, or perhaps more importantly what should have been used to encode graph like things such as map/lists/objects in the 2000’s

Lisp?

josteink• 7 years ago

That this answer is voted down, on HN of all places, is kinda sad.

It may not be the popular answer, but it’s definitely a valid answer.

soapdog• 7 years ago

I think you mean s-expressions instead of lisp and if you do, I'm with you. They are really neat and underused. Now, if you want to carry a whole language runtime for the structured data format you'll probably end up with the "which lisp" kind of problem in which each app end up using something different and then the structured data files are no longer exactly portable (until you devise a portable standard yadayadayada)

alkonaut10• 7 years ago

All you need on .NET/Java in 2007 then is a lisp parser/interpreter. I know they are easy to write, but they aren't as easy to write as something you don't have to write at all.

Let's not forget, many one of these configuration files and data formats are one-off hacks that were meant to be replaced by a real format, a real parser, a real DSL etc. The reason the xml config/dsl/format stuck is because it worked. And it was cheap and easy.

thom3• 7 years ago

XML (and JSON) have the advantage of names, which makes it slightly easier when it comes to querying (and indeed building indexes) over lots of data. I'd be amazed if there wasn't tons of work on this for S-expressions, but I can imagine it's slightly clunky.

carapace• 7 years ago

Abstract Syntax Notation One (ASN.1) is a standard interface description language for defining data structures that can be serialized and deserialized in a cross-platform way. It is broadly used in telecommunications and computer networking, and especially in cryptography.
ASN.1 is a joint standard of the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) and ISO/IEC, originally defined in 1984...

https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One

wpietri3• 7 years ago

The intended purpose is relevant because it tells us the conditions under which something is likely to work well.

XML was vastly overused for a long time. That doesn't make those usages correct, as there were alternatives even then. (It also doesn't make people who overused somehow bad; I think it was a reasonable and necessary mistake.) It certainly doesn't make new ones correct now given that JSON's been around 16+ years. [1]

I think the author here is slightly strong in his criticism; I think XML is great for things that are meant to be long-lived and self-documenting. That is, things that are used like documents. But if I'm passing short-lived globs of structured data back and forth, as with an API, I think JSON's a much better fit, as is Protobufs for more tightly joined code.

[1] https://web.archive.org/web/20030228034147/http://www.crockf...

democracy2• 7 years ago

10 years ago the idea of having json anywhere but in the browser was crazy in the enterprise sphere

dragonwriter• 7 years ago

The intended purpose is relevant because it tells us the conditions under which something is likely to work well.

Not really. Plenty of things suck at their original intended purpose and remain in use because they are very good for some other purpose. (Viagra is an example well-known to popular culture, but hardly unique.)

XML was vastly overused for a long time. That doesn't make those usages correct, as there were alternatives even then.

XML is perhaps not abstractly ideal for many of the purpose it has been used for, but in many cases it was superior to other alternatives for practical reasons, particularly the tooling ecosystem. (JSON is the new XML, and virtually the same thing can be said for JSON in many of its current uses, though it does clean up XMLs two biggest warts, element/attribute distinction and verbosity—though even for human readable formats YAML does the latter even more than JSON while being easier to read, not to mention all the binary options when readability isn't a concern.)

miggol2• 7 years ago

I'd argue that for data storage purposes, you'd like to have a low metadata to information ratio. In the examples the author gives this seems to be the main problem, with way more characters being used for markup than for content.

Compare that to JSON or TOML, which are more human-friendly and waste fewer bytes on structure to convey the same information. When used for data storage, two XML files of the same schema describing two completely different objects are likely to share a large amount of content, which is wasteful and gets in the way.

RantyDave3• 7 years ago

I beg to differ. For a start, XML compresses well and besides, storage is monster cheap these days. XML is a better storage format because it documents what the data is (a title, a reference etc) as well as the data itself.

There are many better reasons to hate XML.

dfox5• 7 years ago

For storage of structured data (and probably even for loosely coupled RPC) you want format that is efficient and schema-oblivious. The bad choice 15 years ago was XML, bad choice today is JSON (the parsing overhead is not negligible) or ProtoBufs (not schema-oblivious). Various binary formats with JSON-like object model seems like the way to go (my choice is CBOR).

And then there is the EU-wide absurdity of WhateverAdES, which invariably leads to onion-like layers of XML in ASN.1 encoded as base64 in XML wrapped in CMS DER encoded message...

rauhl3• 7 years ago

The author also doesn’t suggest what should be used instead to encode structured data, or perhaps more importantly what should have been used to encode graph like things such as map/lists/objects in the 2000’s.

That’s easy: S-expressions. Steve Yegge wrote about this in 2005: https://sites.google.com/site/steveyegge2/the-emacs-problem

Would you rather have:

    <?xml version="1.0" encoding="utf-8" standalone="no"?>
    <!DOCTYPE log SYSTEM "logger.dtd">
    <log>
    <record>
      <date>2005-02-21T18:57:39</date>
      <millis>1109041059800</millis>
      <sequence>1</sequence>
      <logger></logger>
      <level>SEVERE</level>
      <class>java.util.logging.LogManager$RootLogger</class>
      <method>log</method>
      <thread>10</thread>
      <message>A very very bad thing has happened!</message>
      <exception>
        <message>java.lang.Exception</message>
        <frame>
          <class>logtest</class>
          <method>main</method>
          <line>30</line>
        </frame>
      </exception>
    </record>
    </log>

or:

    (log
     '(record
       (date "2005-02-21T18:57:39")
       (millis 1109041059800)
       (sequence 1)
       (logger nil)
       (level 'SEVERE)
       (class "java.util.logging.LogManager$RootLogger")
       (method 'log)
       (thread 10)
       (message "A very very bad thing has happened!")
       (exception
        (message "java.lang.Exception")
        (frame
         (class "logtest")
         (method 'main)
         (line 30)))))

lstamour• 7 years ago

Frankly, I’d rather some form of compressed binary logs, but sure, either works if it includes a stack trace and I need it at the time! Text logs compress well anyway, they just grow larger if/when you process them later... I’m just happy to see objects as log entries instead of plaintext strings. ;)

EdwardDiego3• 7 years ago

I have no strong preference for either, so long as both of them convey the structured information I need.

Although tbh I'm preferring the XML in your example due to the lack of random quotes - why does (record need a quote, but (log doesn't?

The XML seems a lot more consistent.

dependenttypes• 7 years ago

The XML version has the dtd which can be used to validate it though. I am not aware of something similar for s-expressions.

alkonaut10• 7 years ago

The xml, definitely. Without lisp-specific tooling that colours/balances etc, writing 5 consecutive closing parens (and not 4 or 6) is a headache. Also I probably couldn’t choose it on its own merits - I choose what the non programmers that edit the file can use (and they sure don’t have any other editor than notepad).

Then again: I’d usually only ever choose between formats with support already on the platform/standard library, if it was just some config or small data file. If the data is core to the product then of course it might be reasonable to include a new library or even write a parser. I’m talking java and .net now mainly.

Mikhail_Edoshin6• 7 years ago

You'll want XML as soon as it exceeds one screenful :) And this XML is, well, "musused"; it should be that:

    <log>
      <record date="2005-02-21T18:57:39" millis="1109041059800" sequence="1" level="SEVERE" class="java.util.logging.LogManager$RootLogger" method="log" thread="10" message="A very very bad thing has happened!">
        <exception id="123" message="java.lang.Exception" class="logtest" method="main" line="30" />
      </record>
    </log>

I also don't object squeezing the exception attributes into record with some prefix that would make the names unique, like that:

    <record date="2005-02-21T18:57:39" millis="1109041059800" sequence="1" level="SEVERE" class="java.util.logging.LogManager$RootLogger" method="log" thread="10" message="A very very bad thing has happened!" exc-message="java.lang.Exception" exc-class="logtest" exc-method="main" exc-line="30" />

Or, if it's possible to normalize these data, factor out the exception and other attributes and build an index of them so that they can be referenced by an ID:

    <exception id="123" message="java.lang.Exception" class="logtest" method="main" line="30" />
    
    <record ... exception-id="123" />

altmind• 7 years ago

Can I have my gripe with apple plists?

<key>CFBundleDisplayName</key>

<string>TextEdit</string>

<key>NSHumanReadableCopyright</key>

This may be perfectly parsable by a SAX parser storing some state, but its totally not processable by xslt.

k__3• 7 years ago

How old is this format?

I had the impression mobile was some new try at frontend tech, but somehow iOS and Android threw a whole bunch of outdated stuff at me.

I mean, before the iPhone I designed a XML based ETL config system and tried to avoid all the common XML errors, then I start doing a mobile app 10 years later and it's like all that knowledge was forgotten...

mikl• 7 years ago

Yeah, that's awful XML. Ironically, they used to have a decent readable format in NeXTStep, it was only later it was XML-ified.

nwellnhof• 7 years ago

but its totally not processable by xslt.

It's a bit inconvenient but perfectly processable with XPath:

    /dict/key[.='CFBundleDisplayName']/following-sibling::string[1]

spiralx5• 7 years ago

I remember when Neverwinter Nights 2 came out touting that all of its data files were in XML for ease of modifying in user extensions. So I had a look and was it XML? Was it fuck, it was like a GeoCities novice's idea of how to code HTML - absolutely unparseable in any way unless you're the idiot who decided what the codebase needed was another shitty homegrown parser.

And yes, plists suck and make your XPath selectors ugly, although you could write a function to abstract them out.

mojuba2• 7 years ago

That's a very useful and sobering view actually. Unfortunately for the XML format it wasn't designed to prevent its own abuse. But anyway, XML is for documents sounds like a good and acceptable paradigm.

That being said, one subtle and important (and often overlooked) difference between XML and, say JSON is that you can stream XML while parsing it on the application level, whereas JSON can not be parsed by the application due to arbitrary ordering of keys. (Of course lower level parsers use streaming anyway, but that's not the point)

In fact you not only can but you should parse XML while streaming it. This is another common abuse: wherever you look you see some high level function that loads an entire parsed XML structure into memory at once. But once you start asking yourself where the file may be coming from you realize that your system may be open to denial of service attacks. E.g. is your system ready to receive a 16GB XML file?

Bouncingsoul1• 7 years ago

Exactly this, last time I checked the dump of german wikipedia was around 16GB so you'll find these files in the wild

fanf22• 7 years ago

There is no reason you can’t do a SAX-style parser for JSON. A quick bit of searchengineering will find dozens, eg. https://github.com/dgraham/json-stream

mojuba2• 7 years ago

You can in principle, but because the order is not guaranteed, you may find yourself accumulating things in memory. It depends on the task of course, but neither standard parsers nor generators are required to send adjacent JSON entities in a specific order.

I remember someone describing a trick where instead of sending a JSON array they'd just send a stream of JOSN objects, one per line, so that the receiving end could parse the data in a streaming fashion. But that's not JSON anymore.

miggol2• 7 years ago

The worst example of this that I deal with regularly has to be the libvirt domain XML.

https://libvirt.org/formatdomain.html

It does occasionally put information outside of the tags, but because there's no logic to when, it's nearly worse.

tehjoker• 7 years ago

It is difficult for me to see what the real issue is with examples given. It seems to be more an aesthetic preference of the author rather than a technical argument. People can use formats for whatever they want. :P

If you told me that the transmission and parsing rate is too slow for their application, that's a real dig at it.

mehrdadn• 7 years ago

I think it's a bit like trying to explain why a Python REPL isn't a substitute for a calculator? Like it can of course do what you want, and you can't "see" what's wrong if you just take what you see literally (you'll obviously get the same answers regardless of what tool you use), but it's just... not meant for that.

kbenson• 7 years ago

So, what is XML good for? If it's not good for data as everyone says (and I'm not inclined to argue), but it is good for documents, what kind of documents are we referring to? A defined metadata on a text document? A template used with data to generate something else? Is a configuration file a document or data? Where would I want to use XML that something like JSON, a text document, or some combination thereof wouldn't be better?

I'm not being facetious, this is an honest question. Where are the "right" places to use XML?

jerf• 7 years ago

I wrote this four years ago: https://news.ycombinator.com/item?id=11446984

There are points of disagreement between me and the author, although I wouldn't get too passionate about them.

Super-short version, reading over it again, is that XML is very good at what it does, but it really ought to be seen as a relatively specialized data format. It's really good at certain tasks, best-of-breed for a couple of them, and degrades rapidly as you get away from that. JSON is a fairly cheap & fast general-purpose format that's OK at a lot of things, isn't necessarily great at much, but as you get into more specialized use cases, also tends to degrade. Being a general-purpose format, perhaps arguably it degrades more "slowly", but it does degrade.

Properly understood, IMHO, their use cases don't overlap much if at all, and the combination of them may cover a lot of space, but are still far, far from the only serialization formats you'll ever need.

TallGuyShort• 7 years ago

Think of semi-structured documents, where you have a list of pre-defined sections. I've seen it in use by insurance companies for case reports, in real estate for appraisals. And of course we've all seen it work well in the form of HTML. There's some structure to all of these examples, but mostly for annotating text sections. You need some flexibility built into the schema to add fields as needed, but you're not dealing with various map / list / primitive data types as a matter of routine. Just making this one up, but if LaTeX wasn't already the standard, I'd also use it if I was digitizing the content academic papers, for instance. You have an a header with metadata, abstract, the body, citations. There's some structure, a need to add some metadata, perhaps flexibly over time, but mostly it's just a document.

k__3• 7 years ago

I worked on a project that used XML as document format for config files.

arkitaip3• 7 years ago

Sounds like a - gasp! - data format.

scarygliders3• 7 years ago

XML for config files is utter madness.

Why use XML when INI files are way easier to read, and especially edit if needs be?

Why add a ton of additional sugar on top of something as simple as "a=b" for config files?

throw0101a• 7 years ago

Where are the "right" places to use XML?

Tim Bray, co-editor of the XML spec, writing in 2006 on the topic:

Use JSON: Seems easy to me; if you want to serialize a data structure that’s not too text-heavy and all you want is for the receiver to get the same data structure with minimal effort, and you trust the other end to get the i18n right, JSON is hunky-dory.
Use XML: If you want to provide general-purpose data that the receiver might want to do unforeseen weird and crazy things with, or if you want to be really paranoid and picky about i18n, or if what you’re sending is more like a document than a struct, or if the order of the data matters, or if the data is potentially long-lived (as in, more than seconds) XML is the way to go.

* https://www.tbray.org/ongoing/When/200x/2006/12/21/JSON

He was also editor of the JSON RFCs:

* https://tools.ietf.org/html/rfc7159

* https://tools.ietf.org/html/rfc8259

g_b• 7 years ago

A right place to use XML is when you want to write structured & reusable content, for example when writing documentation. See DITA [1].

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

jolmg3• 7 years ago

DocBook[1] is probably another good use of XML.

[1] https://en.wikipedia.org/wiki/DocBook#Sample_document

devnulloverflow• 7 years ago

What is the exact relationship? The history as I remember it is:

1. SGML (Simple Generalised Markup Language) came first. 2. HTML was a specialisation of SGML, it took off because of the web, and is probably the only reason for SGML to become famous. 3. XML was then invented as a generalisation of HTML, perhaps by people who had never heard of SGML.

And I seem to remember DocBook is an SGML thing, it was invented between steps 2 and 3.

Finnucane2• 7 years ago

Just the sort of thing you would think of as 'documents'--the texts of books, manuscripts, and the like, where structure may be somewhat arbitrary. For instance, I work with a few different text corpuses--one of which is an actual dictionary, with entries, definitions, usage examples, etymological information, and bibliographic references. Another is a collection of poetry manuscripts, with annotations for line breaks and editorial emendations, both from the author and other editors (i.e, places in the manuscript with crossouts, interlineal notes, marginal notes, etc).

I mean, in theory, you could do this in JSON or some other data structure. But you would go insane and be shooting yourself in the head before long.

jolmg3• 7 years ago

you could do this in JSON or some other data structure

I'm not sure you could. For example, in another comment, I mentioned DocBook[1]. How would you do the following sample document in JSON?

  <?xml version="1.0" encoding="UTF-8"?>
  <book xml:id="simple_book" xmlns="http://docbook.org/ns/docbook" version="5.0">
    <title>Very simple book</title>
    <chapter xml:id="chapter_1">
      <title>Chapter 1</title>
      <para>Hello world!</para>
      <img src="hello.jpg"/>
      <para>I hope that your day is proceeding <emphasis>splendidly</emphasis>!</para>
    </chapter>
    <chapter xml:id="chapter_2">
      <title>Chapter 2</title>
      <para>Hello again, world!</para>
    </chapter>
  </book>

Would you make each <chapter> into an object? But you have 2 <para> children in there with an <img> in between. And one <para> has an additional <emphasis> in the content. I can't think of a good JSON schema equivalent to this.

[1] https://en.wikipedia.org/wiki/DocBook#Sample_document

dwaite• 7 years ago

I absolutely agree. Where XML shines is when you could take just the text content - strip out the all the markup elements and attributes, document, comments, etc - and have a text document that still makes some sort of sense.

This AFAICT was actually why SVG has a few bizarre choices - such as putting all the drawing commands into attributes. A browser that doesn't understand an embedded SVG document in its HTML would be left with just the text contents.

tootie• 7 years ago

I've been getting along fine using JSON for pretty much everything. That being said XML has some very sophisticated features like rigorous schema definition, a query language, a formal include syntax, comments (that's a big one), it's a lot easier to do multi-line content and in fact you can mix normal text and structured data.

The include syntax doesn't get enough love. It's crazy that JSON doesn't support it.

dfox5• 7 years ago

The issue with all the XML sophistication is that essentially only environment where all that really works is when you use XML as a markup language for technical publishing (ie. DocBook, DITA, ...) and in fact as a less convenient but more modern and cool SGML replacement.

Random applications that read XML just aren’t going to implement fully validating parsers, because it is lot of completely unnecessary work. Also in the article mentioned pattern of storing everything in attributes mostly comes from the fact that working with CDATA nodes in XML is major PITA wrt. whitespace handling and coalescing adjacent nodes.

Mikhail_Edoshin6• 7 years ago

XML is absolutely excellent for markup. There's no competitors here.

Markup consists of two things: a scalar (a string usually, but can be a binary sequence) and associated structured data: smaller scalars, records with fields, and lists (there's no "etc." here, that's all).

The structured data are either discovered in the scalar by parsing or added to it by marking it up. Parsing applies to binary data and artificial languages (although there are parsers for natural languages as well), marking up to structures that cannot be parsed out, but can be added manually, usually during authoring, but also during after-the-fact indexing.

XML stores both the original scalar and the structure together in a single piece. There's extensive tooling for processing the result.

Practical examples:

1. Parse a C file and do something else with it than compiling. E.g. you want to publish it, index with cross-references, transform maybe: XML shines here (you'll normally want to add XSLT to it).

2. Author text and do something with it. If it's Markdown, apply a minimal parsing and save the resulting AST in XML. Same for reST and any other format out there: just get it into XML as soon as you can and process the XML from that point. Whatever you want to produce (XML, man pages, PDFs), XML toolchain will help you to get there.

3. Mark up existing text. E.g. you have a collection of letters and want to index all references to people. XML would be a very good choice here too. (I'd say that marking up and indexing all existing texts of the humanity would be a very important project. There's already a lot of effort to publish them, and marking up and indexing is what naturally comes next.)

4. I'd venture to say that even binary formats would benefit from conversion to XML and back because of what's possible with XML toolchain (I'm thinking mostly about transformation, but indexing would also be good.) E.g. read a collection of MP3 files, parse them out into what they have (ID3 tags of different versions at the beginning or end, APE tags, other such tags, and MPEG frames), and then do what you want: index by anything, clean up, add extra information that cannot be expressed in tags (classification for classical music or argentine tango, for example) and so on.

PS: Since XML can store structures alongside a scalar, it can also store structures alone: just drop the scalar. It's a very good format for structured data, absolutely not as bad as it's usually painted. Much better than JSON, actually. But you have to prepare it well.

PPS: Scalars and structured data are, of course, the natural parlance of all other programming languages out there, so everything XML does you can do without XML. But it also means that XML is not as foreign as it appears. There is some friction between getting data out of XML and putting it back, but it's about same as with SQL.

benibela5• 7 years ago

The worst XML use I have ever seen are lists generated by Lazarus. Every list. For example in the project files you have:

    <RequiredPackages Count="5">
      <Item1>
        <PackageName Value="LazUtils"/>
      </Item1>
      <Item2>
        <PackageName Value="treelistviewpackage"/>
      </Item2>
      <Item3>
        <PackageName Value="internettools"/>
      </Item3>
      <Item4>
        <PackageName Value="LCLBase"/>
        <MinVersion Major="1" Release="1" Valid="True"/>
      </Item4>
      <Item5>
        <PackageName Value="LCL"/>
      </Item5>
    </RequiredPackages>

sedachv11• 7 years ago

Compare that to SGML:

https://leancrew.com/all-this/2014/09/sgml-nostalgia/

SGML really needs a revival.

hyperman1• 7 years ago

I once got a really nice one:

Software v1.0: Config is a binary blob and everybody curses the nasty editor provided by vendors.

Software v2.0: Config is in XML. Thank god!

Oh wait.

<Binaryblob><Byte value="65"/><Byte value="99"/> ....

robofanatic• 7 years ago

I guess the correct answer depends upon the requirement.

I like this way

  <root>
   <item key="name">John</item>
   <item key="city">London</item>
  </root>

So I can use this xpath to get the person's name:

  //root/item[@key="name"]/text()

Not sure what would be the xpath to get the name if the XML was

  <root>
   <item>
    <key>Name</key>
    <value>John</value>
   </item>
   <item>
    <key>City</key>
    <value>London</value>
   </item>
  </root>

This is a better example:

  <employees>
   <employee id="1">
     <field name="name">John</field>
     <field name="city">London</field>
   </employee>
   <employee id="2">
     <field name="name">Jack</field>
     <field name="city">Boston</field>
   </employee>
  <employees>

scandox• 7 years ago

If you accept the author's premise then all of these (including his) are wrong uses of XML.

elFarto• 7 years ago

The XPath for the second one would be:

//root/item/key[text()="Name"]/../value/text()

icebraining• 7 years ago

Alternatively

  //root/item[key[text()="Name"]]/value/text()

commandlinefan4• 7 years ago

Well, actually, an even better example is:

    <employees>
      <employee id="1">
        <name>John</name>
        <city>London</city>
      </employee>
      <employee id="1">
        <name>Jack</name>
        <city>Boston</city>
      </employee>

I know what you’re trying to do there - you’re trying to “future-proof” your schema by allowing introduction of arbitrary new elements. Which means that there’s no standard way to guard against somebody omitting a required field (like “name”) or adding a new field like “creditCardNumber” - other than to document your acceptable key values in a non-standard format and add defensive code that a validating parser would have given you. You’re better off taking as much advantage of the format as you can.

bullen• 7 years ago

I would love to know what people think of my XML node-graph/tree editor I made before JSON became mainstream (my excuse): http://rupy.se/logic.jar

It basically names the tag what you name the node. :S

- You link/unlink nodes (I called them entities! Xo) by right-click-dragging between them.

- You copy stuff by right-click-dragging to an empty space.

- You delete by grabbing something by left-click-holding and pressing the delete key.

- Oh, and nodes are completely tree structure expandable, just drag-drop attributes on nodes and nodes inside nodes.

The editor uses lightweight rendering so you can have a ton of elements with good performance.

(I know, not super intuitive; but very handy once you know about these.)

davidw• 7 years ago

I love the quote I originally saw on the Nokogiri (Ruby XML lib) site:

"XML is like violence – if it doesn’t solve your problems, you are not using enough of it."

scarygliders3• 7 years ago

I have always thought that using XML as a format for storing and retrieving configuration files, was complete insanity.

Which is why I still use the simple, effective, INI format for configuration files for applications I write.

XML for config files is madness personified.

deanCommie• 7 years ago

I think that Software Engineers should take influence from Authors (after all, are we not all craftsmen/artisans?) and incorporate the philosophies from https://en.wikipedia.org/wiki/The_Death_of_the_Author

The idea, for those not familiar, is that once a work of art is published (a novel, a poem, a song, a painting), it speaks for itself, and authorial intent no longer matters.

That is, meaning and purpose are in the eye of the beholder/consumer. And there is no right or wrong way to "interpret" art. If someone finds meaning that the author did not intend, it is just as valid as a deeply hidden but intentional allegory they intentionally placed in when they were writing.

The relevance to software is it applies to APIs, specifications, standards and formats.

There is no such thing as users using your software or specification "wrong" - if they insist on doing so, the meaning has evolved. Evolve with it or die.

rkagerer• 7 years ago

That's a little extreme but you raise a good point. I think a talented spec designer anticipates how their work might be interpreted / used / abused, and, like an adroit villain, nudges their audience toward tenets their grand scheme seeks to achieve.

hashberry• 7 years ago

a simple test for determining if an XML schema is well designed: remove all tags and attributes from it ... If what you have left over does not make sense ... you shouldn't be using XML at all.

Magento 2 (acquired by Adobe for $1.68bn) uses XML to render its layouts. Here's some fun XML for the checkout page:

https://github.com/magento/magento2/blob/2.3-develop/app/cod...

unilynx3• 7 years ago

XML is a actually wonderful format for data and especially extensible configuration if you combine it with XML Schema and CSS selectors...

- XML schemas give you a ready-to-use format to describe, restrict and document available configuration settings. The unique keys help and a libxml2 gives ready to use validation, even if you may need to 'translate' its error messages before showing them to end users

- XML schemas also support other annotations so you can further generalise your configuration readers by recording the necessary bindings in the XML schema itself, allowing to use it eg to define application user interfaces.

- Almost any text editor can do basic syntax validation preventing most typographic errors, and even better if they can read the schema

- XML schemas are extensible using <import>s, but namespaces still enforce some separation. You can define explicit points where plugins extend your configuration format using <any>

- Human editable - closing tags are noisy but more readable than }],{}] when non-programmers may have to edit these files just to add a few extra textfields to an UI.

- Better datatype support, eg datetimes, by using XML schemas. JSON's type support is too limited

- Support for comments!

- And once you've verified the schema... CSS selectors and DOM APIs to actually process the XML documents.

YAML fixed quite a few things, but still no date times or as far as I know standardised approaches to defining schemas. And I've lost count at how any attempts exist to add schema information or namespacing to JSON...

But for markup... we may be better off to just use markdown inside CDATA blocks

sedachv11• 7 years ago

XML schemas give you a ready-to-use format to describe, restrict and document available configuration settings.

As someone that likes and uses s-expressions, I never thought I would find myself defending XML, but here we are in 2019, no one understands basic parsing theory anymore, and file formats have "evolved" to hot garbage like YAML and TOML.

XML has some great tools in comparison:

http://xmlsoft.org/xmllint.html https://relaxng.org/

But for markup... we may be better off to just use markdown inside CDATA blocks

SGML can still make a comeback: https://leancrew.com/all-this/2014/09/sgml-nostalgia/

novok2• 7 years ago

YAML and TOML were optimized for human reading and writing, like markdown. XML & even JSON are not as human optimized, but still human usable.

tannhaeuser5• 7 years ago

SGML can still make a comeback

Hey, you should checkout http://sgmljs.net (my project).

scott_s• 7 years ago

I agree. The author and other commenters here have not proposed an alternative which provides two features I consider critical to a generic data format: schema specification and validation; and easy parsing support in many ecosystems. JSON and Yaml don't seem to have mature, widely adopted schema specification and validation. And I'm not aware of anything outside of XML, JSON and Yaml which have such wide parsing support in so many different ecosystems.

theamk4• 7 years ago

JsonSchema is pretty good -- it is not as widely used as XSD, but it has libraries for most languages.

And of course JSON is the easiest thing to parse in scripting languages, like Python and Ruby -- the entire API is one line, and then you have a native structure you can work with.

tannhaeuser5• 7 years ago

But for markup... we may be better off to just use markdown inside CDATA blocks

No we arent't. markdown itself is literally specified as a shortform of HTML [1], and can be translated into canonical angle-bracket syntax using SGML short references (though not completely eg. markdown reference links require unlimited forward lookup). This gives a canonical representation of markdown in SGML/XML even if you don't use SGML.

[1] https://daringfireball.net/projects/markdown/

mickduprez• 7 years ago

XML is/can be much more than a markup language and yes, it can be used very badly but this is usually by inexperienced 'data wranglers' who don't understand the difference between data attributes and data proper.

While XML can seem cumbersome (compared to JSON say) it is a very good 'data transport' tool when used correctly with a sensible schema (XSD).

For example, we use XML as a 'vendor neutral' data format to export/import CAD geometry and associated data for town utilities such as buildings, pipes, roads etc. All this data has to be validated against the schema to ensure its correctness. Using a schema like this enables the city council to import this XML into the GIS system to be used for asset management, financial planning etc.

A good schema can be key to sharing XML effectively between departments/applications and being a markup language this data can also be viewed independently using XLST.

h2odragon• 7 years ago

I present, in the spirit of 'worst XML ever', the docs for ScriptXML:

https://www.egosoft.com:8444/confluence/display/XRWIKI/Missi...

This is the language used in the game X4 Foundations (and others in the series). An example of its use (mine, i claim no grace in it):

https://github.com/h2odragon/dragoncommands/blob/master/aisc...

... XML is not a great format for an extension language, I have to say.

Gibbon12• 7 years ago

Eclipse project files are also hot garbage.

LameRubberDucky• 7 years ago

For those wondering what you do with XML as a document markup language, see the XML document that is the specification for XML. I had to look at the page source to determine it really is an XML document. Looks like an HTML document.

https://www.w3.org/TR/xml/REC-xml-20081126.xml

yellowapple3• 7 years ago

Jesus. That's slick. Almost makes me appreciate all the bells and whistles of XML.

Almost.

spiralx5• 7 years ago

I've got a stylesheet I wrote that turns HTML or XHTML into a fully indented and highlighted representation of itself which I was quite proud of :) I used to spend a lot of time writing XSLT and XQuery lol.

commandlinefan4• 7 years ago

The first rule of XML is: whatever you're doing with it, that's not what it was for.

micimize• 7 years ago

I can't find much to corroborate this article's take. RDF is a stark counter-example - a standard from the W3C. It has endorsement from Tim Bray, one of XML's co-authors.

tannhaeuser5• 7 years ago

In 1996, XML was invented.

XML wasn't an original invention; it is specified as a proper SGML subset. From the XML spec:

The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document.

Now I totally agree that SGML and XML aren't for service payloads and config files. The sole purpose of markup languages is representing structured text. And arguably, SGML fills this role much more adequately than XML today as it can represent (via the SHORTREF mechanism) custom Wiki syntaxes such as markdown and others, and in contrast to XML, can deal with the largest corpus of markup out there eg. can parse HTML with all its minimization features such a omitted tags, enumerated and unquoted attributes, etc. See [1] for a practical introduction (disclaimer: link to a tutorial I held last month at ACM DocEng).

[1] http://sgmljs.net/docs/sgml-html-tutorial.html

catalogia• 7 years ago

SGML's implied close tags are a pain in the ass though. End tags in XML are overly verbose, but at least they're required.

tannhaeuser5• 7 years ago

You control whether an element requires start- and end-element tags in your element declaration via "O" (letter O as in "omissible") in the respective tag omission indicator position:

    <!ELEMENT e - -(f,g,h)    -- no tag omission -->
    <!ELEMENT f O - (#PCDATA) -- start-tag omission -->
    <!ELEMENT g - O (#PCDATA) -- end-tag omission -->
    <!ELEMENT h O O (#PCDATA) -- both start- and end-
                                 tag omission allowed-->

What's painful about end-element tag omission?

gnuarch• 7 years ago

Can't find the source, but vaguely remember this line from a Usenet or mailing list post, maybe by Tim Bray:

The lack of </> in XML is a crime against humanity.

just_myles• 7 years ago

I agree with this portion 100%

The correct way to express a dictionary in XML is something like this:

<root> <item> <key>Name</key> <value>John</value> </item> <item> <key>City</key> <value>London</value> </item> </root>

In the past I used to create scripts that exported xml from relational data but didn't really understand the right way to build and structure them.

billsix• 7 years ago

RIP Eric Naggum

http://www.schnada.de/grapt/eriknaggum-xmlrant.html

Quarrelsome• 7 years ago

I once had to write a data layer in xml, in-situ with a lifespan for up to hours, as more data was appended to it. An invalid xml document that you couldn't load in many xml apis for 99.9% of its lifespan. I begged and pleaded the lead architect to use an sqlite db for the elements of the data until the transaction was complete and then merely produce the xml file at the end, but no.

It had to survive power outs too.

lmilcin• 7 years ago

And JavaScript was never meant to be used to build applications...

There are many, many more inventions that are used for different purposes they were meant for.

The Internet was created so that US can withstand nuclear attack and it was never meant to be primarily used to spread advertisements.

Get over it.

billpg• 7 years ago

XML with only tags and attributes (nothing but ignored spaces between '>' and '<') is a reasonable structured data format.

XML is almost always misused

Related Stories