XML has several advantages over JSON: it's much better at self-documentation and the schema validation tools are more powerful. Namespaces compose elegantly. XML has a bad reputation due to enterprise-y abuse of the technology, but that does't mean it's a fundamentally bad idea.

I never saw a nice use-case of namespaces. Maybe you can show me one?

So far I have only seen namespaces used by Inkscape to state that a SVG is a still image using 3 different name-spaces in one hierarchy. Does it not just add complexity to need to support different standards at the same time

> I never saw a nice use-case of namespaces. Maybe you can show me one?

Basic example: If you want to mix data from several formats in one document.

Let's say you want to create an RSS-feed which contains information about "new stuff" whatever that new stuff is. This "new stuff" may actually be other XML-data which can be parseable and processable by other tools (like for instance new builds, deployments, whatever). This data probably has a format of sorts individually, independent of the RSS-feed itself, which has its own well defined format.

Now let's say both the RSS-feed and the custom-data contains both a "link" element and a "title" element. Without namespaces, these are bound to collide.

Some examples of problems which then arises:

- How can a RSS-library validate that the feed format itself is correct?

- How does a RSS-feed library know which "link" elements it should process and display, instead of only ones which belongs to the feed definition?

- How does the RSS-processing library know that it should most definitely ignore that title which belongs to the deployment metadata?

- Etc etc

Namespaces allows you to combine data from different formats without ever running the risk of the data getting mixed up by whoever consumes them.

It's a really basic feature, and it's at the core of the whole eXtensible bit of XML. I'm honestly surprised by both the amount of people who find this confusing and how few people are able to realize the value of such a simple construct.

I guess too many "1337 HTML ninja rockstars" got introduced to XML as "just another angle-bracket markup format" and never actually bothered to learn anything about absolutely foundational XML basics.

> Basic example: If you want to mix data from several formats in one document.

Can you get more concrete on why you would want to mix formats? So far what I have seen namespaces were used just to extend one format.

> Now let's say both the RSS-feed and the custom-data contains both a "link" element and a "title" element.

Easily avoided if you just extend one format, but can happen if you would want to mix existing formats because of some reason.

> - How can a RSS-library validate that the feed format itself is correct?

You still need some code that parses the non-RSS part anyway, which can validate it. Don't you usually have just one parser that parses RSS and the non-RSS at the same time? If not, how are you passing your non-RSS XML tree-parts from the RSS-only library to the "new stuff"?

> You still need some code that parses the non-RSS part anyway, which can validate it.

Provenly incorrect.

How many RSS validators validates the contained HTML (as HTML, not as per XML well-formedness)?

If you ever have to annotate one tree using a completely separate tool, you need to do something to ensure the names you choose are different from the ones used by whatever produces the tree. You can choose odd names, but there's no guarantee. Namespaces can provide that guarantee, via uniqueness of URIs, ultimately relying ICANN.

Almost certain this doesn't qualify as "nice", but: Namespaces make XSLT more powerful than one might think at first, because they allow you to write XSLT that generates XSLT (and so on...) by switching a namespace to a different one upon output generation.

Of course, the result is often barely readable anymore, so there's that.

Edit: On the other hand, the difference between XSLT-namespaced elements and all the others in a stylesheet is the one thing that makes basic XSLT readable, since you don't have to use a full meta-language just to create simple elements.

> XML has a bad reputation due to enterprise-y abuse of the technology, but that does't mean it's a fundamentally bad idea.

The fact that the Javascript-world is still copying XML-techcology and ideas which was formalized, standardized and ready for use over a decade ago, should pretty much be all the proof you need for that statement.

But hey. JSON is new and shiny!

Do you or Sir_Cmpwn have a small, real-world example of elegant XML namespace composition in the context of Wayland?

I didn't see XML namespaces used in the example given in the article, so I'm curious how Wayland leverages them.

Not to mention XML supports comments.

Oh, just put an object key named "//" with your comment as the value, and change the software to ignore such keys! /sarcasm

My rage over JSON not supporting comments grows every time I have to write some config file in it. Crockford tells you, "Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser."[0]... 99% of the usecases for JSON offer no way to insert a preprocessor into that pipe.

[0] https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...

It doesn't matter; it's just a machine readable protocol description.

Why?

Json il less verbose and is the de facto standard for the web, json is easier to parse by javascript (by the browser or node.js), and a serialization/deseriazation is unique, in xml you could put some infos on the attributes oand other on tags or as parameters. instead of <event name="gamma_size"> <arg name="size" type="uint"/> </event>

{"type":"event", "name":"gamma_size", "arg": {"name":"size","type":"uint" }

>Json il less verbose and is the de facto standard for the web, json is easier to parse by javascript (by the browser or node.js)

Wayland is not the web. None of these technologies are involved in Wayland.

>{"type":"event", "name":"gamma_size", "arg": {"name":"size","type":"uint" }

Your example is more verbose and harder to read... XML is definitely misused in many applications where JSON is appropriate but this is not one of them.

JSON has problems, but that's why we have TOML:

    [gamma_size]
    type = "event"
    args = [
       { name = "size", type = "uint" }
    ]

XML isn't what I would choose here because there's no need for text markup. TOML is both simpler and friendlier than XML in this case.

I do agree that it doesn't matter much.

We have TOML in the sense that TOML is currently v0.4.0 and bears an explicit warning that the specification is unstable should be treated accordingly.

That's unfortunate, but there are a lot of projects out there that depend on TOML, and it hasn't changed since 2015. It's de facto stable at this point.

The author has said as much: https://github.com/toml-lang/toml/issues/330

Wayland predates TOML, and I think TOML would be worse than XML for this use case.

I'd be happy to know your reasons why.

Overall, XML is too verbose; in particular, the text markup features of XML are needless complexity.

It's not. It's barely more verbose than JSON and a hell of a lot more readable. JSON is appropriate for machines to talk with. XML is appropriate for writing documentation or API specs.

Thanks for the insight. Some of the comments revealed why xml was picked. I personally agree that depending on the problem you must pick the right tools and what might be a good suit in a context it might not be the best fit in another. Moreover, there are probably more mature and performant parsing libs in c for xml than for json.

However, XML might be overkill as it might be too complex for this particular scenario. XML parsing it's complicated and from time to time there are bugs in those parsers. A simpler format might also get the job done and might be safer. However XML might provide flexibility to scale.

Finally, this is what Torvalds said about XML when someone suggested to use it in git:

> XML is crap. Really. There are no excuses. XML is nasty to parse for humans, and it's a disaster to parse even for computers. There's just no reason for that horrible crap to exist.

Relevant xkcd: https://xkcd.com/927

It's USB-C ;)