AI's take on XML

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.

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.

TOML or bust

Not long before AI just tells me to google it, or read the manual.

This is what happens when people make content for points.

OP already admitted he made it up.

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.

The future if text documents were Json:

City_pic.png.xml

I hate writing a serialized format

I mean, that's why it's serialized. It's not supposed to be written by hand, that's why you have a deserializer. 🤦

This is fine.

We slowly need to interface with an app at work that uses fixed-width too. It does not sound that bad if you hear it but it sucks to figure out where you are missing whitespace when most fields are not used and therefore all whitespace. Oh, and of course there are a lot of fields, also are aligned/formatted differently based on their type and has thin/no/wrong documentation. And I have yet to find a simple but decent "debugger".

Oof. That sounds horrible

perplexity.ai

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

fake

Ah... Too bad (:

Unironically.

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

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.

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.