Useability is not good

Posted Dec 19, 2025 10:23 UTC (Fri) by gioele (subscriber, #61675)
In reply to: Useability is not good by mbunkus
Parent article: Conill: Rethinking sudo with object capabilities

I'd add:

- TOML: no difference between "this field is set to null" and "this field is not set and thus it has the default value". (See https://lobste.rs/s/h50lml/toml_1_1_0_released#c_wiibz1 for a longer discussion.)

And I'd remove:

- XML: attributes vs data in child elements

Why is that a problem? Many IDLs offer you a way to specify non-structured metadata about an object (attributes) or encapsulated structured/non-structured data (child elements).

to post comments

Useability is not good

Posted Dec 19, 2025 11:13 UTC (Fri) by mbunkus (subscriber, #87248) [Link] (3 responses)

>> - XML: attributes vs data in child elements

> Why is that a problem? Many IDLs offer you a way to specify non-structured metadata about an object (attributes) or encapsulated structured/non-structured data (child elements).

Due to how the distinction between data & metadata isn't actually adhered to or, god forbid, enforced somehow. Just check the Apache Tomcat server.xml configuration files. While you can map that data into hash-array structures, you cannot do the reverse without additional information provided to the writer (stylesheet, explicit writer configuration etc.).

Again, I'm only arguing from a standpoint of having a format that humans can easily maintain. In this situation the duality or overlap of functionality of attributes & child elements is a clear detriment. Not only do you have to remember which options exist, but also whether the parser/application expects those to be an attribute or a child element. Furthermore, element & attribute names are often spelled differently, again placing more cognitive load on us humans.

Sure, good tooling & stylesheets fix some of those concerns. And no, XML isn't unusable, of course. I'm just… frustrated by the lack of a format I can consider really easy to use for us humans with only very minor drawbacks.

Useability is not good

Posted Dec 22, 2025 9:15 UTC (Mon) by taladar (subscriber, #68407) [Link] (2 responses)

Where XML really loses is its ridiculous escaping system with giant lookup tables, making every XML library comparatively huge and escaping support a pain to implement.

Useability is not good

Posted Dec 22, 2025 9:37 UTC (Mon) by gioele (subscriber, #61675) [Link] (1 responses)

> Where XML really loses is its ridiculous escaping system with giant lookup tables

What are you referring to exactly? XML's escaping system defines exactly 5 entities (lt, gt, amp, apos, quot), a way for DTD authors to define their own entities (sadly known for the "billion laughs" attack), and a generic mechanism for referring to Unicode codepoints (ø for ø). None of that requires "giant lookup tables".

Maybe you're mixing XML with HTML, whose predefined list of char entities is quite long and contains unusual things like " &npart; (partial differential, combining long solidus overlay)"? https://en.wikipedia.org/wiki/List_of_XML_and_HTML_charac...

Useability is not good

Posted Dec 22, 2025 10:24 UTC (Mon) by taladar (subscriber, #68407) [Link]

Well, HTML and pretty much any concrete XML format I have ever had the displeasure of dealing with. The basic design of the entity system is just deeply flawed when compared to much simpler escaping mechanism in other text formats. I'd much rather deal with five levels of backslash escaping in a template that generates shell code that uses regular expression parameters to modify some other stuff with backslash escaping than with XML and that is not because nested backslash escaping is fun to deal with (especially when each level has slightly different things that need backslash escaping).