I mean we have a generation that thinks XML is bloated & JSON is superior but those two formats are about the same on performance & compressed size–which was the point. The non-plaintext-readable formats are superior along a lot of metrics but harder to debug & ultimately less common.

The future if text documents were Json:

City_pic.png.xml

Lots or file formats are just zipped XML.

I was reverse engineering fucking around with the LBX file format for our Brother label printer’s software at work, because I wanted to generate labels programmatically, and they’re zipped XML too. Terrible format, LBX, really annoying to work with. The parser in Brother P-Touch Editor is really picky too. A string is 1 character longer or shorter than the length you defined in an attribute earlier in the XML? “I’ve never seen this file format in my life,” says P-Touch Editor.

Aren’t most XML parsers faster than JSON parsers anyway?

TOML or bust

Unironically.

Given the choice between S-expressions and XML, I will choose S-expressions.

That’s why professionals use XML or JSON for this kind of projects and SQL for that kind of projects. And sometimes even both. It simply depends on the kind of problem to solve.

Alright, the YAML spec is a dang mess, that I’ll grant you, but it seems pretty easy for my human eyes to read and write. As for JSON – seriously? That’s probably the easiest to parse human-readable structured data format there is!

JSON not supporting comments is a human rights violation

Over time I have matured as a programmer and realize xml is very good to use sometimes, even superior. But I still want layers between me and it. I do output as yaml when I have to see what’s in there

Depends on how complex it is. Ever see the XML behind SharePoint? 🤮

I see you’ve never worked with SOAP services that have half a dozen or more namespaces.

perplexity.ai

Like DuckDuckGo’s AI’s, but with sources? Sounds cool, thanks!

fake

Ah… Too bad (:

YAML

To each their own indeed.

;)

Since XML can have attributes and children, it’s not as easy to convert to JSON.

Your JSON example is more akin to:

<address street_address="21 2nd Street" city="New York" ...></address>

I’m not sure now that I think about it, but I find this more explicit and somehow more free than json. Which can’t be true, since you can just

{"anything you want":{...}}

But still, this:

<my_custom_tag>
<this> 
<that>
<roflmao>
...

is all valid.

You can more closely approximate the logical structure of whatever you’re doing without leaving the internal logic of the… syntax?

<car>
<tyre> air, <valve>closed</valve>  </tyre>
<tyre> air, <valve>closed</valve>  </tyre>
<tyre>      <valve>open</valve>  </tyre>
<tyre> air, <valve>closed</valve>  </tyre>
</car>

Maybe I just like the idea of a closing tag being very specific about what it is that is being closed (?). I guess I’m really not sure, but it does feel nicer to my brain to have starting and closing tags and distinguishing between what is structure, what is data, what is inside where.

My peeve with json is that… it doesn’t properly distinguish between strings that happen to be a number and “numbers” resulting in:

myinput = {"1":"Hello",1:"Hello"}
tempjson = json.dumps(myinput)
output = json.loads(tempjson)
print(output)
>>>{'1': 'Hello'}

in python.

I actually don’t like the attributes in xml, I think it would be better if it was mandatory that they were also just more tagged elements inside the others, and that the “validity” of a piece of xml being a certain object would depend entirely on parsing correctly or not.

I particularly hate the idea of attributes in svg, and even more particularly the way they defined paths.

https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Paths#curve_commands

It works, but I consider that truly ugly. And also I don’t understand because it would have been trivial to do something like this:

<path><element>data</element><element>data</element></path>

YAML is good for files that have a very flexible structure or need to define a series of steps. Like github workflows or docker-compose files. For traditional config files with a more or less fixed structure, TOML is better I think

Having an easy on the eyes markdown that is also easy to parse would be cool.

But YAML does these things:

https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell

which are not excusable, for any reason.