When XML Beats JSON: UI Layouts
engineering.instawork.com
engineering.instawork.com
- For starters, it's overly verbose. If you've worked with stuff like XAML in WPF or XML layouts on Android, you know how quickly those files tend to get bloated.
- It does not lend itself well to reuse compared to, well, actual code. Which means there tends to be a lot of repetition. Which leads to more bloat.
- Editing XML kind of sucks. You're more at risk of making silly typos that won't be caught at compile time.
- XML namespaces make an already verbose language even more verbose, not to mention just generally confusing.
- At some point you will need to access your user interface from your application code. Which means you end up with silly stuff like findViewById() to bridge the gap, adding even more boilerplate to your code.
- You essentially have to learn two different sets of APIs which do the same thing. <Button title="blah"/> vs button.setTitle("blah"). Why?
The only real strengths of XML are that 1) it's declarative, 2) it's hierarchical, and 3) it's diffable. But code can be too, without all of these other drawbacks.
Fortunately it seems like the industry is starting to figure this out with things like SwiftUI and Jetpack Compose. I really think we're going to look back in a few years and think it was ridiculous that we used to do this stuff in XML.
Designers would most likely be familiar with XML given their HTML background, but they wouldn't necessarily know C#.
If Swift UI expresses the full fidelity of the API in the designer (e.g. expressing custom states and animations, keyframes, etc. on a custom button), then my point doesn't apply. If the full range of designer responsibilities cannot be achieved without dropping into code, then Swift UI isn't a real counterexample.
I am really curious how often XAML has been used by a designer who didn't know C#. Most of the XAML I've seen (in non-trivial apps) has a lot of code-like constructs in it. If you don't know what's going on under the hood, how are going to correctly declare your data bindings (for example)?
Those code-like constructs are UI behavior (e.g. how to transition from checked to unchecked for a checkbox). While they do take learning, they are not strictly code.
Also, Expression Blend can interact with every part of XAML in full-fidelity. Designers need not worry about the code-like parts of XAML at all.
> If you don't know what's going on under the hood
I suppose the workflow is that the design team would log a ticket for the development team, who would expose said binding and add it to the UI as a placeholder. I'm not sure exactly how this is supposed to work, but Microsoft did have a project which combined Unity and WPF to solve this exact workflow (I forget the name), and they were using it internally.
---
Personally, I can see the benefit as I do work at a product company. Developers get bugs pretty often to do with "element X is 1 pixel off," usually from the design team (one designer was known to open screenshots in paint to measure distances). If you can empower the designers to just create real UIs instead of mockups, it would get done correctly in the first place. Vue SFCs come close to achieving this, but fall short in terms of state (you still need JS to add/remove CSS classes).
Either way, it isn't fair to compare Swift UI to XAML as Swift UI doesn't seem to attempt to solve this at all (even if XAML doesn't solve it perfectly). Swift UI is closer to System.Windows.Forms.
It's not a language that anyone would want to do the actual software implementation in. That's important because, if you pick an existing language, then everyone who plans to use some other language is going to see that choice and assume it means that their language is either unsupported or will be a second-class citizen on that UI toolkit. They might not be wrong.
Creating a whole new language that's custom-tailored for UI layout avoids that problem, but will also be off-putting, since people will perceive that they have to learn a whole new language just to use your UI toolkit.
And just slapping it into a mess of library calls that people can call from any language is perhaps the worst choice of all. GUI toolkits, for whatever reason, always end up being object-oriented. Meaning that you've got to export an object-oriented API. Meaning you've got to either implement it in an object-oriented language that probably has a deeply incompatible and possibly not even standardized ABI such as C++, or you've got to go to great lengths to Greenspun an object-oriented system into a procedural language that can export a C-style ABI. Neither of those is fun.
In summary. . . yeah, XML is an awful choice. It's easily the worst option, aside from all the other options, which are even worse.
- User interfaces are very prone to have big files, because there tend to be a lot of different components. I don't get how XML will add more bloat, other than having the <> tags for defining elements.
- XAML lets you define custom controls. I'm not familiar with Android XML, but in any case it's not an issue of the language but of the framework.
- Again, a fault of the framework. Visual Studio, for example, checks your XAML for errors, both when writing and when compiling.
- I don't think namespaces are confusing (most programming languages have some concept of namespaces), but I agree that one could have more facilities to avoid specifying namespaces everywhere.
- Yes, but most of the time you shouldn't access the user interface from the application code, as coupling them tends to create ugly code that is prone to mistakes and failures. For me, this is an actual advantage of XML for UI, it makes it more difficult to create an interface out of spaghetti code.
- Well, one is declarative and the other one imperative. As long as you want to have both types, it doesn't matter what language you use.
For me, there's not that much of a difference between SwiftUI/Jetpack Compose and equivalent XML code. UI definitions are going to be messy no matter what.
I disagree that this is an inherent property of user interfaces. In fact I think it's a bit weird that we focus so much on abstractions and when it comes to the code we write (DRY principle, etc), but then when it comes to XML we wave our hands in the air and declare "well that's just the way it has to be".
> - XAML lets you define custom controls. I'm not familiar with Android XML, but in any case it's not an issue of the language but of the framework.
Custom controls allow you to reuse entire widgets, but what about code reuse?
> - Again, a fault of the framework. Visual Studio, for example, checks your XAML for errors, both when writing and when compiling.
No, ultimately it's the fault of the fact that you're trying to shoehorn a bunch of stuff into XML attributes (as strings) that weren't strings to begin with. As I said below, ever make a typo in a binding?
> - I don't think namespaces are confusing (most programming languages have some concept of namespaces), but I agree that one could have more facilities to avoid specifying namespaces everywhere.
This is admittedly worse on Android where almost everything needs to be prefixed with android:, except stuff that comes from the support library, plus these other handfuls of exceptions (which is definitely a framework problem), but even stuff like x:Name vs Name is unnecessarily confusing in WPF.
> - Yes, but most of the time you shouldn't access the user interface from the application code, as coupling them tends to create ugly code that is prone to mistakes and failures. For me, this is an actual advantage of XML for UI, it makes it more difficult to create an interface out of spaghetti code.
That sounds good in theory. In practice, you end up with a lot of code-like constructs in your user interface. Every XAML file I've ever seen is full of bindings, converters and converter parameters, triggers, etc. You might insist this is not code because it lives in an XML file but it sure looks a lot like code to me, just shoehorned into a document language format.
In other words, while we strive hard to avoid spaghetti code, it seem like we don't apply the same principles to avoid spaghetti XML.
> - Well, one is declarative and the other one imperative. As long as you want to have both types, it doesn't matter what language you use.
False dichotomy, IMO. You can build a declarative UI in your code without resorting to XML.
> For me, there's not that much of a difference between SwiftUI/Jetpack Compose and equivalent XML code. UI definitions are going to be messy no matter what.
Have you actually worked with either of these frameworks?
<foo:bar xmlns:foo="urn:foo-corp">
<foo:baz />
</foo:bar>
<f:bar xmlns:f="urn:foo-corp">
<f:baz />
</f:bar>
<bar xmlns="urn:foo-corp">
<baz />
</bar>
Inline functions and classes dont exist in either, JSX doesnt have to deal with xml's namespaces, and you dont need to construct an entire document- fragments are defined in functions at as granular a level as you like.
I do agree personally that I prefer tsx over the other alternatives, just pointing out that it is a pretty nice step up over something like flex or xaml.
The point of HTML isn't to make it easy to lay out a document, it's to have an easily understandable pure-text representation of hierarchical data that can be read by computers/users. Light, well-formatted, semantic HTML isn't an engineering concern, it's a UX concern.
Of course HTML can be used as a layout tool, but that's not its primarily purpose, otherwise it would include decent 2-way data bindings for tables.
You could read it and understand it because it was the same language you used. If there was a problem you could debug it.
I never felt more productive than when my UI declaration was just code.
Inevitably you need to mix some logic in the layout language and then debug it (For each render this thing, binding syntax etc.) now you have a weird programming language that is hard to debug and remember syntax for, or you could just use a normal programming language, maybe one that supports some declarative constructs.
SwiftUI gives me hope, would like to see something similar show up for the .Net World.
The GUI designer actually just ran your code to display in the designer, which mostly worked, sometimes it could break if you form relied on runtime dependencies and you could code around that by specifically checking for DesignMode == true in your code.
I am not saying this was perfect but it had a lot of advantages. Now you see SwiftUI and the like going back toward that model.
You could override what it was doing in the main class file though if needed pretty easy. Again if it did break it was just aode and threw a normal exception in the designer, usually revolved around something that didn't work right in DesignMode so you had to check for that explicitly.
I'm not sure about any C#-focused efforts.
1: https://github.com/fsprojects/Fabulous
2: https://github.com/fable-compiler/Fable (transpiles F# to JS)
3: https://github.com/elmish/elmish
Layouts are trees of widgets. Layouts are themselves widgets so repetition in the tree can be reduced.
You use XML, C++, or both to define a widget. The UI Compiler will turn that XML into C++.
That means further code reuse can leverage the C++ type system. All widgets are QWidgets, and MyProgressBar inherits from QScrollBar.
And you (or, at least I) never write .ui files by hand, they've got a GUI designer tool. And the tool supports your custom widgets by treating them the same as the known widget type it inherits from.
Accessing XML-defined widgets from code is the same as C++ defined widgets, because the compilation step means they are. Class member names come straight from the XML file.
The QObjects are constructed in a way that understands the UI hierarchy, and you can programmatically walk that hierarchy using the variable names. (You do have to tell objects their own names in the non-XML-generated code.)
One particular pet peeve of mine is the fact that it won't catch typos in data binding. If I have IsEnabled={Path IsEnabeld} in my XAML, the designer won't catch it. At runtime, the error is silently ignored. It just doesn't work, and no tooling, nothing other than triple checking every line of code will catch it.
Also it's really bad about picking up dependencies cross package, although it might be a problem in my org's config.
Code generally isn't declarative or hierarchical unless your language is those things as well. A declaratively defined interface in C# would end up being some like a bunch of strings or enums passed to some object constructors. At that point I'd rather a an XML implementation that can be verified and processed with tools.
"- For starters, it's overly verbose. If you've worked with stuff like XAML in WPF or XML layouts on Android, you know how quickly those files tend to get bloated."
I frequently write WPF code these days and don't find it any more verbose than attempting the same thing in C# statements. If anything, it's less verbose and it has the added benefit that it's all organized in the same group of files.
"At some point you will need to access your user interface from your application code. Which means you end up with silly stuff like findViewById() to bridge the gap, adding even more boilerplate to your code."
I don't know about Android, but in WPF, you just add a name attribute to your ui element and reference it by name.
"Editing XML kind of sucks. You're more at risk of making silly typos that won't be caught at compile time."
Hasn't really been my experience. Syntax errors are caught by the editor typically and further errors do get caught at compile time for XAML at least. Some errors don't get caught, but these are the same errors that would get missed if I attempted the same thing in C# code.
I should clarify and say code can be declarative with the correct language support. I agree that it's probably not well suited to C# in its current state.
> I frequently write WPF code these days and don't find it any more verbose than attempting the same thing in C# statements. If anything, it's less verbose and it has the added benefit that it's all organized in the same group of files.
Here are two examples I would consider overly verbose in XAML:
1. Triggers, DataTriggers, EventTriggers, MultiTriggers, etc. Here we're dealing with the fact that XML is not a programming language and lacks basic control structures, so we've gone ahead and defined our own mini-programming language just so conditional values can be expressed in XML. Why?
2. Anything having to do with overriding ControlTemplates.
> Hasn't really been my experience. Syntax errors are caught by the editor typically and further errors do get caught at compile time for XAML at least. Some errors don't get caught, but these are the same errors that would get missed if I attempted the same thing in C# code.
Ever make a typo in a binding?
I agree that Visual Studio is really good at helping you out where it can, but at the end of the day we're still trying to shoehorn programming constructs (objects, properties, enums, etc) into a document language format by shoving everything into XML attributes (where everything is a string) and there is a fundamental impedance mismatch between the two. Good tooling only goes so far.
Ok, but which language do you think would work? Lisp? I like the things you can do with macros and s-expressions as much as the next guy, but you're still left with the question of what should people using C# (which has neither of those things) use to make GUIs.
"1. Triggers, DataTriggers, EventTriggers, MultiTriggers, etc. Here we're dealing with the fact that XML is not a programming language and lacks basic control structures, so we've gone ahead and defined our own mini-programming language just so conditional values can be expressed in XML. Why?"
Correct, all the different sorts of trigger are verbose. But, to answer your question as to 'why?' the reason is because we need a deterministic way to express conditional formatting. If we attempted to accomplish the same tasks with hooks we'd have the problem of intermixing imperative, state-full, code with logic that is supposed to be more deterministic. I've written code like that for WinForms like that and it's ugly and hard to debug.
If you were to try to implement triggers with code behind C#, it would still be very verbose because you wouldn't be writing actual C# logic. You'd be doing something like declaring an object with trigger conditions and results and it would be at least as verbose as the XAML triggers, that is, if you wanted to accomplish the same thing with the same guarantees as with XAML triggers. The problem here isn't really the XML, but the fact that there isn't really an available language that solves the relevant problem. It's not like you could use an `if` statement.
"Ever make a typo in a binding?"
I have. I've also made typos when writing viewmodel objects that implement the `INotifyPropertyChanged` interface to similar effect.
My underlying point is with platforms like iOS and Android adopting declarative UIs, combined with languages like Swift and Kotlin evolving in parallel to better support them, I think we will eventually be able to move on from being stuck with XML.
I've done a bit of WPF and a fair amount of Qt Widgets, and never once did the actual XML content matter since it was mostly putting the control at a place that looks good in a UI designer.
> Which leads to more bloat.
I'd like to know your definition of "bloat".It's not like 100kb or 500kb of XML are going to translate into 100kb or 500kb executables or runtime memory use, since the XML is generally only used at compile time before translation into code.
> Editing XML kind of sucks. You're more at risk of making silly typos that won't be caught at compile time.
well, Qt's main IDE marks the UI xml files as read-only so not much chance of that on that side.
> At some point you will need to access your user interface from your application code. Which means you end up with silly stuff like findViewById() to bridge the gap, adding even more boilerplate to your code.
... no, you will just refer directly to a variable that was generated in a precompilation pass - you can inherit from or compose the generated object depending on if you prefer to type `ui->myLabel.setText` or `this->myLabel.setText`.
> You essentially have to learn two different sets of APIs which do the same thing. <Button title="blah"/> vs button.setTitle("blah"). Why?
You don't if you just use the UI designer.
Qt's XML schema makes sense and very easily translates to the C++ it generates. If one wishes they can write the XML themself using just their knowledge of the Qt Property System, the Layout System, and the very basics of how the XML is laid out. If they want to just use a designer tool, that's fine too however Qt's UI designer makes life very difficult from the perspective of version control and actual usability.
The UI designer doesn't respect any Canonical form of the UI files. This means that each time you save the file it more or less jumbles the entire thing up based on however it decided to hold it in memory. This turns tiny changes (what should be maybe 2-3 lines of XML) into massive ones (100s to 1000s of lines of XML shuffled just enough to shake off any semblance of contiguous history in the VCS). Likewise, it adds arbitrary property data to items that 95/100 times are unintended (setting default geometry sizes based on the sizes of the UI elements in the demo window) or are simply meaningless (storing the default value as a user selected property despite the user requesting to use the default).
It doesn't help that the UI of the designer is finicky as hell (layouts) and adding custom UI components is a hassle via the editor while it is exceedingly easy in the XML.
It's a bunch of small things like that that have resulted in teams I've worked on in the past refusing or at least strongly discouraging the committing of changes made by UI designer into VCS. It's really a shame too since a good UI editor is a boon for development and Qt has a really nice UI library.
As people already pointed, code isn't inherently declarative or non-verbose. Some of the most popular languages for creating GUIs (Java, JS, C#) aren't either.
> It does not lend itself well to reuse
There isn't any inherent feature for code that will enable the kind of reuse you need when declaring a GUI either. You'll get it naturally in Lisp, you may be able to hack something in Haskell, and you can create a hacky DSP in in Python or Ruby, but if your GUI is in Java, CS, or JS you are out of luck.
> silly typos that won't be caught at compile time
That's a tooling issue. At Python, Ruby or JS you it is inherently more an issue than on XML, at Lisp it will vary with the actual idiom.
> At some point you will need to access your user interface from your application code
> You essentially have to learn two different sets of APIs
Well, that's bad design. There's nothing (except well, a lot of work) stopping a library from making the entire interface manipulation by actions made over XML. Granted, that is much easier and more natural in a DSL or in declarative reflexive code, so you do have a point, but it can be fixed by a lot of polishing over the worse fundamentals.
- Editing XML is actually a lot easier than JSON. Thanks to XML schemas, completion works really well in XML and very poorly (if at all) in JSON.
- Also, XML allows comments, which JSON doesn't.
- You don't need `findViewById()` in 2019 and haven't in a while, really: there are plenty of alternatives available (synthetic accessors, Kotlin, ButterKnife, etc...).
Accessing objects from code is not a problem due to compile time code generation, no findById just access the field. Due to the powerful macro system in Haxe you even get in code autocomplete for objects defined in xml before running compilation.
For code reuse it allows easy way of defining custom widget classes based on xml file and using custom widgets in xml file.
In my experience with Qt bloat usually comes from graphical editors that add unnecessary properties you wouldn't have set in code or GUI systems that don't support creating reusable subcomponents.
<ol>
<li>...</li>
...
</ol>
new OrderedList(
new List<ListItem> {
new ListItem(...),
...
}
);
ol(
li(...),
li(...)
)
But honestly, does it really matter? Either choice isn't terrible at all.
<android:whatever xmlns:ext="urn:my-corp/ui-ext">
<ext:my-button this="..." that="..." />
</android:whatever>
<xsl:template match="ext:my-button">
<!-- expand into what you need -->
</xsl:template>Android Jetpack also tries to bridge the gap of this in android, even though here you manually have to write some glue code yourself to create this reactive layer.
<Employee name="Michael Scott" title="Regional Manager">
<Employee name="Dwight Schrute" title="Ass. Regional Mgr" />
<Employee name="Jim Halpert" title="Head of Sales">
<Employee name="Andy Bernard" title="Sales Rep" />
<Employee name="Phyllis Lapin" title="Sales Rep" />
</Employee>
<Employee name="Pam Beesly" title="Office Administrator" />
</Employee>
The simplicity of JSON is an advantage: it prevents people from mucking it up with too much nonsense like this. Of course, you CAN make unreadble JSON as well, XML just makes it so much easier.
Fixed that for you :) https://www.youtube.com/watch?v=wA9kQuWkU7I
JSONs simplicity was out the window before it became a formal spec. The original designer of JSON omitted comments from the final spec because people were using them to create processing directives.
There are multiple differing implementations of JSON parsers, the most notable differences between them being some allow comments while others treat them as errors. There's also JPATH, JSON Schema, and JSON Transform.
JSON is the new XML. It has been and will continue to be abused to fit all the possible corner-cases, at the expense of simplicity and readability. Just like XML.
EDIT: Oh, and instead of CDATA, we now simply base64 encode arbitrary objects and pack them into JSON encoded strings. Is this really an improvement?
I think that's more of an indictment of HTTP than XML or JSON. Maybe we should have a better standard for exchanging non-textual data with websites.
On the other hand HTTP is in fact a binary protocol and there is perfectly good way to transport sets of binary objects with associated metadata: MIME multipart/whatever. With multipart/byteranges even being part of HTTP itself and multipart/form-data being one of the "core web technologies".
And even still, that just doesn't look intuitive to me. Probably because there is no distinction between an employee and a list of employees linked to a parent employee?
<Employees>
<Employee id="1" name="Michael Scott" title="Regional Manager" />
<Employee id="2" boss-id="1" name="Dwight Schrute" title="Ass. Regional Mgr" />
<Employee id="3" boss-id="1" name="Jim Halpert" title="Head of Sales">
<Employee id="4" boss-id="3" name="Andy Bernard" title="Sales Rep" />
<Employee id="5" boss-id="3" name="Phyllis Lapin" title="Sales Rep" />
<Employee id="6" boss-id="1" name="Pam Beesly" title="Office Administrator" />
</Employees>It's easy to make a concise representation of DOM trees as JSON: http://m1el.github.io/jsonht.htm
I find it really sad that people don't know or consider s-expressions to represent trees.
(Department {:name "Scranton Branch"}
(Employee {:name "Michael Scott" :title "Regional Manager"}
(Department {:name "Sales"}
(Employee {:name "Dwight Schrute" :title "Ass. Regional Mgr"})
(Employee {:name "Jim Halpert" :title="Head of Sales"}
(Employee {:name "Andy Bernard" :title="Sales Rep"})
(Employee {:name "Phyllis Lapin" :title="Sales Rep"})))
(Employee {:name "Pam Beesly" :title "Office Administrator")))[div.btn.blue.p-4 {:disabled true} "Button Text"]
<byte>
<bit>1</bit> <bit>1</bit> <bit>0</bit> <bit>1</bit>
<bit>0</bit> <bit>1</bit> <bit>1</bit> <bit>0</bit>
</byte>
It is not concise. Here is an example of a single div tag overhead:
["div",{"class":"some classes"}, ... ]
<div class="some classes"> ... </div>
(div (class= "some classes") ... )
So why does it need to be wrapped in a format that's verbose, underspecified, doesn't have comments, doesn't have namespaces and doesn't have any notion of metadata?
Because the OP article doesn't even consider s-expressions, so I'm working with the tools I was given.
Personally, I find it frustrating that EDN (or some other form of s-exprs) aren't widely adopted.
<ieee-754:byte xstdversion="2008" nstid="two's complement" _archext="x86-64">
<ieee-754:bit arity="2">1</ieee-754:bit>
<ieee-754:bit arity="2">0</ieee-754:bit>
...Just try to write the JSON equivalent of:
<div>The <a href="https://www.json.org/">JSON format</a> was invented by <em>Douglas Crockford</em>.</div>
I think I prefer the XML :-)
Edit: I agree that tagged text is a clear win for XML - for pretty much everything else I'd go for JSON.
Edit2: HN ate my formatting, but probably not a bad thing ;-)
[
"div",
[
"The ",
[
"a",
{ "href": "https://www.json.org/" },
[ "JSON format" ]
],
" was invented by ",
[
"em",
"Douglas Crockford"
],
"."
]
]
edit: though it again gets confusing when the 0 index is sometimes the element type and sometimes the straight text... so never mind I guess the problem persists.
[ "div", "The ", [ "a", { "href": "https://www.json.org/" }, "JSON format" ], " was invented by ", [ "em", "Douglas Crockford" ], "." ]
First thing in array is element, if there is an object at the second location then that's the attributes?
[:div "The" [:a {:href "https://www.json.org/"} "JSON format"]
" was invented by " [:em "Douglas Crockford"] "."]
1: https://holmsand.github.io/reagent/
2: https://github.com/Day8/re-frame
If the second argument is an object/dictionary, it's attributes. Otherwise, it's the first child. Alternatively, the ambiguity can be resolved by using null/0 instead of empty attributes.
R uses markdown + a separate file with the output cached and while the non-rendered file is easier to version the whole thing is a lot more difficult to handle.
["div", 0, "The ", ["a", {"href": "https://www.json.org/"}, "JSON format"], " was invented by ", ["em", 0, "Douglas Crockford"], "."]
Just imagining a JSON that starts with
"dummy": "don't remove this or the API will mis-align this across two structs!!!"
"comment": "The foo widget needs blah blah ...", [
["the ", {}],
["JSON format", {"link": "https://www.json.org/"}],
["was invented by ", {}],
["Douglas Crockford", {"bold": true}],
[".", {}]
]1. The xml denotes that the whole thing should be wrapped in a div, and shouldn't just be considered a paragraph. With only lists you can't denote what kind of level you're at, unless you force each level to always carry the same meaning (which makes the format weaker than XML).
2. Setting "bold" to true isn't the same thing as emphasizing the text. Typically 'em' is italic, but more importantly a nested 'em' should no longer be italic. To achieve this with JSON you're forced to combine formatting and structure in a way that CSS was designed to prevent.
{ "string": "The JSON format was invented by Douglas Crockford",
"structure" [
[ 0, 48, "div", {} ],
[ 4, 13, "a", { "href": "https://www.json.org" } ],
[ 32, 48, "em", {} ]
]
}Upd: The three kinds of data: the string, the structures (div, a, em), and their position in the string.
But on the XML side, the baby was thrown out with the bath water, while JSON started developing its own abuses. TOML and YAML come in and muddy the waters a bit more.
This is only 1 article, but maybe the world is ready to discuss the possibility that the pendulum swung too far?
That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this. It's one of the things I really like with OpenBSD's various subprojects like PF¹ and OpenSMTPD² and relayd/httpd³, and I'm semi-actively working on a way to do similar things in Erlang/OTP applications⁴. The only alternative that matches that level of expressiveness (besides just doing all configuration directly in the host language) is s-expressions.
¹: https://man.openbsd.org/pf.conf
²: https://man.openbsd.org/smtpd.conf
³: https://man.openbsd.org/relayd.conf.5 / https://man.openbsd.org/httpd.conf.5
If I'm going to make them learn another configuration language, it's going to have something more to offer than just 'simpler than YAML'. Maybe Starlark for more powerful configuration applications (think infra-as-code where YAML/JSON/etc clearly isn't powerful enough) or if someone ever builds it, "JSON with comments and multiline strings" which offers simplicity without compromising familiarity. Actually, it would be really interesting to hear what people's ideal configuration languages would look like.
> That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this.
I'm not really familiar with this. I'll have to read up.
YAML is all sorts of strange.
JSON needs comments and support for trailing commas. Since that isn't going to happen.... TOML!
For example, XAML does an excellent job in declaring your UI. Its use of namespacing, and how you can use child nodes to declare properties of an object, makes it highly flexible albeit slightly verbose.
JSON is a tree structure. It is dictionaries and arrays mixed together in a hierarchy.
Don't get me wrong, I prefer JSON in most cases. But XML does have many valid use cases. Perhaps you haven't had an opportunity to see its beauty. You can't blindly say JSON > XML or JSON < XML, or "XML sucks" -- this shows ignorance.
JSX does a better job.
I hate XAML, it doesn't add anything except verbosity over just using C#. The original goal of XAML was to allow bindings to multiple programming languages and to allow designers to use a suite of amazing tools to finished designs off to developers for implementation.
What ends up happening is developers write XAML, then they write C# to back up what XAML can't do, then they have a complex build stage to shove all this crap together, but instead of XAML just being transpiled to C# it has its own run time thing that hosts compiled XAML files.
JSX by comparison is a trivial transformation to JavaScript. It is easy to read, and it does not try to replace JS control structures.
In fact you could probably trivially transform a JSX syntax to ANY C type of language, I know there is a proposal (implementation?) for a JSX-like to Dart.
The sheer awesomeness of JSX is hard to describe if you haven't used it. It is like something asked "what is the simplest, easiest to understand templating language we can possibly create?" and out popped JSX.
My favorite part of JSX is how it doesn't try to have control structures in it. Everyone else gets this wrong and adds some sort of string types DSL to their templating language.
JSX doesn't do that. If you want to map over an array and spit out a bunch of elements, you just do so in JavaScript/TypeScript.
XAML is a lot like Python object constructor syntax with all named parameters except one positional parameter that is a list of child objects (obviously, explicit closing tags rather than a closing square bracket and paren is a difference, but structurally it's m almost identical.) It's certainly a convenience for declaring certain kinds of object trees, especially if your main programming language doesn't have a similarly succinct object construction syntax. JSX is effectively a way of adding an equivalent object constructions syntax to the host (JS) language, rather than requiring it to be in separate code files.
Throw in parsers that all act differently (some parse comments, some don’t), and processing directives, and it becomes clear that yes, the pendulum has swung too far.
There is an amazing JSON schema syntax out there, 100% better than the official one. It is called TypeScript, and I am sad that the TS compiler can't be made to pop out JSON validators (their philosophy being nothing at all runtime).
There is a project (I forget its name) that will insert itself into your build steps and use TS type definitions to validate JSON.
Seriously the TS syntax is great, why is anything else being used to write a schema?
The only thing I'd add to the TS syntax is the proposals to add field validation using regexs, or some type of field name validation format. There are times when TS can't model my JS objects, e.g. I have a bunch of GUID field names that map to objects of a certain type, and I have some other field names that are 100% not GUIDs, I promise, mapping to some other stuff.
This is what schema, transforms, and paths are: they're a declarative way to address these tasks in XML. It's natural there will be attempts to reinvent them for JSON.
- write a sax event based parser that scaled but was low level
- use a DOM parser with a fairly convoluted API. The combination of attributes and children makes for wordy accessors.
Both YAML and JSON provide formats that more readily deserialize into native map / list / string / number types which at the time was quite convenient.
It was so easy to understand that every person who was able to use a computer would pick it up quickly. This was not the case for HTML, my guess is because there are a ton of HTML tags and that can be overwhelming for a certain type of audience, whereas here there are at most 10 tags to learn.
The framework I'm talking about still exist, it's called XIMPEL [1] (sadly SMIL kind of died). It may seem like a weird thing, but IMO it's the only open-source framework that has an intuitive way to make non-linear storytelling easy on the web easy. People can kind of hack a choose your own adventure media story with YouTube, but XIMPEL really is so much better at it because it's actually made for that purpose. And the biggest reason why XIMPEL is simpel because it uses XML as its template language.
People just see the tags as lego blocks and build non-linear media essays, stories or even small (media-focused) games with it.
I find this hard to believe. I know many people who use computers but are not IT professionals or even hobbyists. Without an easy to use GUI they can't accomplish much. I couldn't imagine them picking up anything to do with XML.
If you scope it down to UI developers you're taking less than 1% of people. Far from everyone. Even if you scope it down to IT people it's less than 1% of people.
I’ve been told that clerks at bell labs were using troff because they were told they weren’t programming and I think GUIs have the same opposite effect.
Take for instance insane Excel spreadsheets glued with VBA powering entire businesses, built by accountants and other professionals.
Why not allow authors to define their own names? Like
<SomeWrapper>
<SomeChild />
</SomeWrapper>
https://html.spec.whatwg.org/multipage/custom-elements.html#...
https://github.com/w3c/webcomponents/
https://developer.mozilla.org/en-US/docs/Web/Web_Components/...
I wrote this code in another comment, but imagine if you could hook functionality to an element via defined attributes. With custom elements, you have to add the functionality via a script, and they aren't system functions (from what I can remember, I may be wrong).
<LabelList list>
<LabelItem label listItem>
</LabelItem>
</LabelList>
- the LabelList element hooks into the systems "list" behavior
- the LabelItem element hooks into the systems "label" behavior
- the LabelItem element hooks into the systems "listItem" behavior
<ul is="label-list">
<li is="list-item">foo</li>
</ul>
<MySemanticLabel label>
</MySemanticLabel>
<LabelList>
<LabelItem label listItem>
</LabelItem>
</LabelList> <li>
<label>
</li>> This means there’s no officially supported way to represent the list of movies in an element attribute. We can hack this by encoding the list into an attribute using a comma delimiter:
<Users>
<User
first="Michael"
last="Scott"
favoriteMovies="Diehard, Threat Level Midnight" />
<Users>
<User>
<first>Michael</first>
<last>Scott</last>
<favoriteMovies>
<title>Diehard</title>
<title>Threat Level Midnight</title>
</favoriteMovies>
</User> <Users>
<User>
<FirstName>Michael</FirstName>
<LastName>Scott</LastName>
<FavoriteMovies>
<Movie>Diehard</Movie>
<Movie>Threat Level Midnight</Movie>
</FavoriteMovies>
</User> <Users>
<User first="Michael" last="Scott">
<favoriteMovies>
<title>Diehard</title>
<title>Threat Level Midnight</title>
</favoriteMovies>
</User>Consider a comparison of examples using JSON schema:
{
"$schema": "http://json-schema.org/draft-04/schema#",
"description": "Modified JSON Schema draft v4 that includes the optional '$ref' and 'format'",
"definitions": {
"schemaArray": {
"type": "array",
"minItems": 1,
"items": { "$ref": "#" }
}
}
...
<schema schema="http://json-schema.org/draft-04/schema#">
<description>Modified JSON Schema draft v4 that includes the optional '$ref' and 'format'</description>
<definitions>
<schemaArray>
<type>array</type>
<minItems>1</minItem>
<items ref="#" />
</schemaArray>
...
This is a good thing. The main issue with XML is how ridiculously overcomplicated and overengineered its design was. This isn't just a matter of usability, it has security implications because it increases the attack surface of anything that uses it (e.g. the XML billion laughs attack).
Citing element attributes as an example of such complexity is hardly reasonable. The JSON example above contains the same complexity, just moved to the application/implementation space, instead of the parser (so your app is more complex to handle it).
> e.g. the XML billion laughs attack
Also not a great example. This is a simple DOS attack, of which there are many other examples: zip bombs, yaml bombs, etc. None of these invalidate yaml nor zip themselves.
There are also far worse attacks on XML than the billion laughs attack (XXE attacks are an entire category in the OWASP top 10).
What these attacks have in common is that they use references. They aren't unique to XML because any format wanting to handle references (like JSON schema!) will have to account for them.
The difference is, since references aren't built into the JSON spec, you have to do it yourself (and protect against attack like this in your own code). Since XML handles this at spec. level, common XML parsers can account for & mitigate for this for you (which fyi, modern ones do).
---
Side note (and a vote in favour of JSON):
By your own metric, JSON is actually "more complex" (in a good way) than XML in one area: value types. XML values are strings. Having value types is one massive advantage of JSON imo.
In that sense, it would be nice to see a language that combines both of these "complexities", to form something better.
Where it belongs...
>so your app is more complex to handle it
There is a trade off between more simple markup and more complex code and vice versa. I would argue it is almost always better that way around because it helps enforce clear separation of concerns. I'm similarly allergic to putting complex logic in template code because that also violates a clear separation of concerns.
>Also not a great example. This is a simple DOS attack, of which there are many other examples: zip bombs, yaml bombs, etc.
This is precisely why it's a great example. YAML has the same problem with overcomplexity XML does. JSON has no such issues.
>There are also far worse attacks on XML than the billion laughs attack (XXE attacks are an entire category in the OWASP top 10).
Right, billion laughs is part of a class of security vulnerabilities that are enabled by XML's bloated design.
>The difference is, since references aren't built into the JSON spec, you have to do it yourself
Except you don't. I'm not sure if I've ever implemented references in any JSON schema I've ever used. It's an entirely pointless feature as far as I'm concerned. I've seen them used in YAML (where it's equally yucky) and every time it's been used it's been as a band aid over deficient schema design that also inadvertently made the markup harder to understand.
>By your own metric, JSON is actually "more complex" (in a good way) than XML in one area: value types. XML values are strings. Having value types is one massive advantage of JSON imo.
I hardly think having 4/5 scalar types counts as spec overcomplication. If you want a measure of how complex each markup language is simply look at the length of the respective specifications. XML is ridiculous.
But when you deal with inherently hierarchical data, trees, XML is good.
Numbers can be expressed, they just have to be parsed on the client. For array, child elements are ordered and form an array naturally.
But client has to know that they're numbers. So you can't just parse XML into JavaScript object without any knowledge about its structure.
> For array, child elements are ordered and form an array naturally.
But you can't express array of 0-length this way without explicit knowledge about structure. And you can't distinguish array of 1-length from an ordinary value without explicit knowledge about structure.
I'm currently working against a REST API which JSON format has three different date formats as sub-elements of the same root object...
<Number value="123" type="i32" />
It's inventory and optimized for certain language types, specifically those that are loose with their numeric types. This includes most scripting languages.
In languages that require specific intrinsic types to be defined for a number, there are usually a lot to choose from and using the wrong one can be a real problem when converting from XML or JSON to a native format.
On a very simple level, what container do we use to encode the following data structures:
[100,4,10,156]
<array>
<num>100</num>
<num>4</num>
<num>10</num>
<num>156</num>
</array>
But what if the next number is much larger? Should we really need to parse all the values to determine the correct data type to use? That seems very inefficient, and we can't even be sure that we'll encounter values that accurately illustrate the range of values in one parsing. What if the next message or file we parse has large values?
For these languages the inherent data type definition of JSON is a poor match, since its looseness does not transfer easily to a language which does not inherently support it. If your target languages supports dynamicaly resizing untyped arrays, untyped key-value maps, and generic number types that support both very big and floating number types automatically, then JSON is an almost perfect representation format for you. If your target language works best when those items are broken into smaller more explicit components, there's a lot of extra work in parsing JSON, and I can see how that makes XML not look much worse in comparison (especially since your parsed data structure will likely be leaner because there isn't the overhead inherent in those convenient magical types, references are rarely as efficient as pointers).
What does that look like when you parse it?
That's why XML Schema exists. So, everything you listed is possible in XML if you don't put aside some specifications on purpose.
And JSON is so self-describing that someone came with... JSON Schema.
https://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com...
The JSON version of the employee org chart is much more semantic and human understandable (to me) as it "cleanly" describes the relationship for reports as a property called "reports" (for those who manage people - they have that property).
But the org chart as XML was anything but obvious to my human eyes, as it was just nested employee elements and at first glance, looked like a single list of employees. Visually interpreting it to know who's a manager, and who reports to whom seems far more difficult in the XML.
But, again, it's in the eyes of the beholder, and one person's clean solution is another person's confusing tangle of brackets.
We need more articles like this, to remember us that we should consider what's best for the task at hand and not what's trendy.
My sniff test is that if you're editing it by hand, JSON is a poor format because you'll want the benefit of a schema or at least a user-friendly format. If you're not, the syntax doesn't really matter so we should evaluate it on technical merits (verbosity, computational complexity for serialization/deserialization, memory footprint, etc).
I use:
- config file formats for config files (usually TOML or INI format) - data formats for data (JSON, protocol buffers, etc) - markup formats (Markdown, XML/HTML) or code for markup
I really don't get why people try to force all use cases onto the same format. Use whatever is well suited for the task, preferring familiarity over unnecessary technical benefits.
The one problem I see is that as developers, we shouldn't give a rat's ass about the otuput format's readability when compared to the API ergonomics. If the API for describing the UI is good enough (Can I do stuff like "App.Transition(App.findOne(Sidebar), 500, {width:"1%"}, {width:"30%"}, Ease.EASE_IN_OUT)" or is it a 300loc tutorial?) then the storage format at the end of the day is not THAT important, at least for me, a guy who does a lot of GUI work every day.
when you are in a formal setting, people like to code review, and in that case, in the absence of some special diff tool, people will complain they can’t review your ui changes in github and suddenly your format matters alot more than before
It's actually amazing to me how many of Flex's great ideas live on in other frameworks not dependent on the Flash Player, and looking at some modern day React often reminds me if it.
https://docs.microsoft.com/en-us/visualstudio/xaml-tools/des...
> However, we’ve created another problem in the form of inconsistency: some user properties are represented as element attributes, others as child elements.
Exactly. I’ve seen XML with element attributes and child elements all over the pace. No rhyme or reason for any of it. It’s especially bad in older systems.
I pushed hard at my last job for the SOA team to build REST/JSON web services. Oracle sold them a product to bridge the gap and they got End Of Life announcements 6 months later! Glad I’m gone.
> XML, on the other hand, optimizes for document tree structures, by cleanly separating node data (attributes) from child data (elements).
Unfortunately, there appear to be some implementation issues here. You have to create a string version of your data to store them in attributes.
So, you lose a bit of context in the conversion.
Such as:
`<Document text="true" />`
Is the text attribute the word _true_ or a boolean _true_. Without referencing some other piece of code or definition there is no way to know.
Whereas in JSON, this wouldn't be necessary, as you can simply remove the quotes and infer that it is not a string, but a boolean.
See this link on stack exchange[1].
[1] https://stackoverflow.com/questions/17604071/parse-xml-using...
> //Gets Street name xmlDoc.getElementsByTagName("street")[0].childNodes[0].nodeValue;
I’d much prefer something like jsonObj.address[0].street;. Personally I like to work with objects over parsing documents trees.
When you are hacking systems together for large/old enterprises the water gets muddy fast.
Technically, there are REST/JSON equivalents, but I don't see them actually used much in the wild - so much of the time with REST APIs you are stuck with whatever half-baked, out-of-date documentation that somebody may or may not have written, or just randomly poking at it through trial and error to discover how it works.
Sometimes even getting a sample of the expected JSON format can be hard. If you’re not versioning you’re APIs you can break everything if the schema changes.
I used to debate this with the SOA manager. Swagger looks ok but never dealt with it in production or saw it in the wild with our customers.
Otherwise, I try to use JSON, where possible, because I am not a masochist.
I LOATHE XML Schema. I have used it for years, and have never memorized it. I still need to look it up like a n00b, every time I use it.
But the simple fact of the matter is, is that so many people and projects have inculcated it into hundreds (if not thousands) of toolsets and specs (Like -Ick- WSDL), that it really is the only viable game.
People tend to like JSON precisely because it eschews the kind of overhead that is the definition of XML Schema.
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"price": {
"type": "number",
"multipleOf": 0.01,
"minimum": 0
},
"currency": {
"type": "string",
"enum": ["EUR", "USD", "GBP"],
"default": "EUR"
}
}
}The thing about XML Schema, is that it is completely "baked into" pretty much every tool and library out there, so you can do "on-the-fly" runtime validation.
JSON is really about minimizing text. It works really well for this.
Another issue, is that JSON doesn't have comments, so it can be difficult to annotate a JSON file.
JSON is so easy to get started with. Some of this is precisely because of the lack of schema.
In Java with the GSON library, encoding/decoding is one function call and for the things I've been doing this just works at least 90% of the time. I've managed to add a JSON option to several endpoints in an application in something like 1-2 hours, including writing tests.
Back when I did Java as a full-time job and we were working with XML a lot, there were whole proccesses and workflows and validations and annotations to get the thing working properly. I think you also had to add a few extra stages to the maven compile process back then to get the schemas and all properly set up and loaded. It's not so much a fault of XML as a format, as of the whole "enterprise" tooling that we were asked to use around it. I really hope that this has got easier now.
It's almost as if the XML library people were thinking in the waterfall model where you specify everything up front, and the GSON people were thinking in the agile model.
I see some comments saying that JSON can represent trees just as well as XML, which is technically true. However, XML natively supports a distinction between node metadata (via properties) and relationships (via child elements) that has to be implied in JSON. For pure-data, this may not matter . But in cases like UI layouts, it's helpful to have the format distinguish between node properties and child components. As others have mentioned, the document use case is also a natural fit for XML by clearly separating the content from markup.
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
- 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.
(I know, not super intuitive; but very handy once you know about these.)
The editor uses lightweight rendering so you can have a ton of elements with good performance.
This is true for any data - once you hit a moderate level of complexity neither JSON or XML really work - you need to build a tool to manipulate the underlying data rather than changing it directly. If you do that then it doesn't matter how readable or 'ugly' the data is because a human being shouldn't need to access it directly. This leads to other benefits you can optimize for like size or parsing speed or redundancy instead.
I think you underestimate the convenience of a text format.
It does not only provide a simple way to generate it, but also provide a way to modify it by hand.
One of the biggest issues with the most popular 'tool-only language' (Excel) is that there is no reasonable way to audit changes. Same goes for UIs that are backed by inscrutable file formats.
Readability and understandability depend on more strict requirements that a text file format may or may not have. Many do, but far from all do.
For instance, JSON files do not have requirements on the ordering of keys. When making a small change to a JSON file, it is entirely legal to reorder every single key, completely destroying the diff, and an automatic tool may very well do this.
And as a counter-example, we could easily use a binary representation of JSON data, but use a diffing tool that normalises key ordering to provide diffs that are more readable and understandable than a text diff of a JSON file, even without malicious reordering of lines.
Of course semantic diffs would be nice; even, or especially, for code for example but while they do exist they haven't seen much uptake because they do not integrate well with existing tooling.
Only if you ignore the bit where I said "once you hit a moderate level of complexity". Text file formats work really well for simple things.
I strongly disagree. SwiftUI is fucking amazing.
https://developer.apple.com/tutorials/swiftui/
Even with your other comment about "until you hit a moderate level of complexity." People are already creating some complex things with it. In fact, they can be more complex than what you can achieve with traditional frameworks when you consider the time it takes; what takes me a day in UIKit etc. takes me a minute in SwiftUI, so I can quickly move on to the next bit.
With declarative UI code I could literally have a usable app in the same time it takes me to struggle with getting separate visual designers + logic editors to agree over a single moderately complex component.
Though, it is several layers of abstraction over what really happens behind the scenes, so I guess a part of your point stands.
If you have a binary format for a tree structure, you almost always end up accruing garbage as you edit it. That always happens in rich HTML editors, for example.
For something like an image editor, the bitmap is OK because it’s not a tree structure and doesn’t balloon out of control as you edit.
Where your image is tree-structured, eg Photoshop layers, the editing tool will generally show you the exact layer tree in a sidebar, so you can make sure it stays clean and tidy.
It’s easiest to keep it tidy when the canonical source is human-readable text. (Although it’s worth watching out for formatting differences. Something like gofmt helps there.)
Yet people do this everyday. So it's not that complex.
Who says this? XML is a great general markup language that every one all ready knows, it's a perfectly valid choice for most things, please use it.
Just don't make yet another bloated outdated markup language like YAML, any "optimisations" turn out to be opinion that doesn't justify the time spent learning a new language.
Do you really want to be known as the guy that made YAML? No you don't.
Whether it is JSON or XML, what I particularly like about both approaches is that both are fundamentally HATEOAS (https://en.wikipedia.org/wiki/HATEOAS)
Everytime you move an existing component into a wrapper, the identation breaks how the diff shows up.
Perhaps we need a XML formatter that instead of pretty formats, sets the indentation to 0, when we commit code changes. However, that makes the source hard to read.
So instead of a diff that reads line
- <panel>
- <textblock>foo</textblock>
- </panel>
+ <vpanel>
+ <panel>
+ <textblock>foo</textblock>
+ </panel>
+ </vpanel>
+ <vpanel>
<panel>
<textblock>foo</textblock>
</panel>
+ </vpanel>
A pretty formatter could solve this problem too.
<vpanel id="vertical-wrapper">
<panel id="heading">
<textblock>foo</textblock>
</panel><!-- heading -->
</vpanel><!-- vertical-wrapper -->
<vpanel id="vertical-wrapper"> <!-- vertical-wrapper -->
<panel id="heading"> <!-- heading -->
<textblock>foo</textblock> <!-- textblock -->
</panel> <!-- -->
</vpanel> <!-- -->
Instead of hard coding your hierarchy into the structure of XML or JSON. Define some basic type information (unique id and node type).
If you have situations where an object can be referenced before it is defined simply make a proxy loading type that listens for it to load.
After that it is a cakewalk:
[
{
id: "UUID OR Rolling Number Per File OR DB Index OR ...",
type: "business",
name: "Dunder Mifflin Paper Company, Inc."
description: "look at me I can be a root type for the graph OR one of many!"
offices: [
list of ids of objects of type "office" or object that wraps this with other metadata (relation object)
]
},
... potentially other business entries,
{
id: see above...
type: "office",
name: "Scranton Branch",
description: "This can describe each branch"
departments: [
list of ids of objects of type "department" or object that wraps this with other metadata
]
},
... other offices,
{
id: see above...,
type: "department",
name: "sales",
members: [
list of ids of objects of type "employee" or object that wraps this with other metadata
]
},
... other departments,
{
id: see above...,
type: "employee",
title: "manager",
name: "Michael Scott",
reports: [
list of ids of objects of type "employee" or object that wraps this with other metadata
]
},
{
id: see above...,
type: "employee",
title: "sales man",
name: "Dwight Schrute",
reports: [
id of self since Dwight needs someone he can trust,
{
id: see above...,
type: "report_meta",
reportee: id of Pam,
visibility: "secret"
}
]
},
... other employees,
etc.,
etc.
]I guess XML might be perfect for when you can't decide between singular and plural and want to leave the problem to others...
Because that's the biggest problem besides charset encoding that JSON helps solving: in JSON, you can be unmistakably clear that a given property is to be interpreted as a list of values, even when the current number is less than two. In XML you can just vaguely communicate that intent with an intermediary "plural element" unless you go full schema.
<A><Bs><B/><Bs/><A/>
{"bs":[{}]}
The article only shows 1 example in 1 format and then moves onto another point.
The reader is left to imagine what the difference is in their head.
Here's my take on what's possible for generating support code for UI tests when the UI is written in a declarative, easily-parseable language: https://samsieber.tech/posts/2019/06/type-safe-e2e-testing-d...
XML is also a query language with XQuery (https://en.wikipedia.org/wiki/XQuery).
XML is also a nested structure path specifier with XPath (https://en.wikipedia.org/wiki/XPath).
XML is also a file format with SVG (https://en.wikipedia.org/wiki/Scalable_Vector_Graphics), OpenOffice XML (https://en.wikipedia.org/wiki/OpenOffice.org_XML), OpenDocument (https://en.wikipedia.org/wiki/OpenDocument), ePUB (https://en.wikipedia.org/wiki/EPUB), DocBook (https://en.wikipedia.org/wiki/DocBook), and many others (https://en.wikipedia.org/wiki/List_of_XML_markup_languages).
XML is also an data/object serialization format with libraries like Jackson (https://github.com/FasterXML/jackson), YAXLib (https://github.com/sinairv/YAXLib), Boost (https://www.boost.org/doc/libs/1_38_0/libs/serialization/exa...), Pyxser (https://github.com/dmw/pyxser), and many others.
XML may not be as elegant as JSON, but it has a wide variety of uses and wide adoption across many programming languages (libraries), and disciplines.
What's nice about JSON is that there's very little ambiguity in how to serialize / deserialize data structures. That's what's so powerful about it. As a result, using "magic" serializers with language-native data structures often works well and has little gotchas.
In general, I think a lot of people hopped onto the XML bandwagon assuming that it would always sanely translate back and forth between XML and native data structures. This is not the case. When XML is the (cough) "best" format, the underlying data structures of different programs operating on the XML will look extremely different. Furthermore, XML terminology will end up leaking into business logic, because the semantics of the document are inseparable from handling it.
In general, I think the biggest sign that XML is the wrong choice is when someone's using a "magic" serializer, or when the data structures very closely follow the document structure. In those cases, JSON was probably a better choice.
See also Erik Naggum's legendary rant: https://www.schnada.de/grapt/eriknaggum-xmlrant.html
<span class="commtext c00">I have yet to read anything that convinces me that XML is good for <i>anything</i>. Just because XML in certain cases is less bad than some other cherry-picked technology, doesn't mean that there aren't other better options.<p>See also Erik Naggum's legendary rant: <a href="https://www.schnada.de/grapt/eriknaggum-xmlrant.html" rel="nofollow">https://www.schnada.de/grapt/eriknaggum-xmlrant.html</a></span>
\begin{spanned}
I have yet to read \textit{anything}...
\end{spanned}
For the purpose of authoring comments on Hacker News (HN), I for one am grateful= that HN doesn't make us type out HTML. I also doubt very much that HN stores our comments in a different representation (e.g. HTML) than the one they were authored in.
The other problem is that HN comments and all those markdown-like formats are very ad hoc. If I copy/paste my reddit comments on HN, or the other way around, it won't always work as expected. In both cases, it has to be translated to HTML to be displayed by the browser, too.
So, the context would be: an export format for complex, multi-paragraphs textual documents with meta-information.
If you add the condition that it be human-readable, I admit I am not able to point to an existing format that is obviously better suited for this than XML.
A well reasoned XML instance can replace HTML for most things from presentation, accessibility, interaction, content negotiation, and so forth. You can apply JavaScript and CSS immediately to an XML instance. You don't get any of that capability with JSON, YAML, or anything similar.
I really think the people who hate XML the most are those are those who lack the imagination to move beyond raw data and query relationships. I agree XML isn't good at this, which is why it completely offloads that capability to a sibling technology: DOM.
I have also never seen anybody with a comfortable understanding of the DOM believe JSON, YAML, and the like fill that void, but then these other technologies do not primarily exist to structure human consumable content directly for human consumption. The most important part of the article you linked to describes markup relevance as a percentage of syntax overhead. The more the described content becomes an extraction of computer oriented data the more that percentage goes up thus making XML progressively a bad decision, but the opposite is also true.
The article really nails its bias in this regard by fixating on data as a facet opposed to information as a structure. When the goal is to provide primarily a structure, as opposed to fundamentally offering a syntax, the cost to scale grows inversely to the quantity of content provided. That is largely thanks to lexical scope, which allows a richer interpretation of context without any additional or specified syntax. That is the nature of information versus data. Conversely, data conveyance schemes that exist to primarily offer a syntax scale proportionally to the content provided because the ratio of syntax to content is static without any additional meaning.
For some clarity on the difference between data, information, and knowledge I suggest the DIKW model: https://en.wikipedia.org/wiki/DIKW_pyramid
> HXML does not use CSS.
I wonder why? XML is perfectly stylable with CSS. Why not let the user reuse their knowledge?
Somewhat canoncial: https://www.w3.org/Style/styling-XML.en.html
Most of these UI layout formats are essentially complex domain specific languages, paired with IDE support. I don't see any particular need to base them on XML, which was intended for marking up documents.
But the way article is put forward is as if using json we cannot achieve tree structure
eg, don't do this, from the article:
<Users>
<User>
<FirstName>Michael</FirstName>
<LastName>Scott</LastName>
<FavoriteMovies>
<Movie>Diehard</Movie>
<Movie>Threat Level Midnight</Movie>
</FavoriteMovies>
</User>
...
</Users>
<Users>
<User FirstName="Michael" LastName="Scott">
<FavoriteMovies>
<Movie Title="Diehard" />
<Movie Title="Threat Level Midnight" />
</FavoriteMovies>
</User>
...
</Users>
(I don't have to wonder if multiple LastNames might be allowed, if I can set a xml:lang attribute on any of them, if the ordering of FirstName and Lastname elements is constrained, etc etc)