I hate writing and reading xml compared to json, I don’t really care if one is slightly leaner than the other. If your concern is the size or speed you should probably be rethinking how you serialize the data anyway (orotobuff/DB)
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.
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
I don’t mind xml as long as I don’t have to read or write it. The only real thing I hate about xml is that an array of one object can mistaken for a property of the parent instead of a list
Hmm, so in tree terms, each node has two distinct types of children, only one of which can have their own children. That sounds more ambiguity-introducing than helpful to me, but that’s just a matter of taste. Can you do lists in XML as well?
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:
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.
Maybe I just like the idea of a closing tag being very specific about what it is that is being closed (?).
That’s kind of what I was getting at with the mental scoping.
My peeve with json is that… it doesn’t properly distinguish between strings that happen to be a number and “numbers"
Is that implementation-specific, or did they bake JavaScript type awfulness into the standard? Or are numbers even supported - it’s all binary at the machine level, so I could see an argument that every (tree) node value should be a string, and actual types should be left to higher levels of abstraction.
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.
I agree. The latter isn’t even a matter of taste, they’re just implementing their own homebrew syntax inside an attribute, circumventing the actual format, WTF.
XML has its strengths as a markdown format. My own formatted text format ETML is based on XML, as I could recycle old HTML conventions (still has stylesheet as an option), and I can store multiple text blocks in an XML file. It’s not something my main choice of human readable format SDL excels at, which itself has its own issues (I’m writing my own extensions/refinements for it by the name XDL, with hexadecimal numbers, ISO dates, etc.).
Some data formats are easy for humans to read but difficult for computers to efficiently parse. Others, like packed binary data, are dead simple for computers to parse but borderline impossible for a human to read.
XML bucks this trend and bravely proves that data formats do not have to be one or the other by somehow managing to be bad at both.
The thing is, it was never really intended as a storage format for plain data. It’s a markup language, so you’re supposed to use it for describing complex documents, like it’s used in HTML for example. It was just readily available as a library in many programming languages when not much else was, so it got abused for data storage a lot.
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!
Sometimes it’s a space, sometimes its a tab, and sometimes it’s two spaces which might also be a tab but sometimes it’s 4 spaces which means 2 spaces are just whack And sometimes we want two and four spaces because people can’t agree.
But do we want quotes or is it actually a variable? Equals or colon? Porque no los dos?
the spec is 10 chapters. everything is unquoted by default, so parsers must be able to guess the data type of every value, and will silently convert them if_they are, but leave them alone otherwise. there are 63 possible combinations of string type. “no” and “on” are both valid booleans. it supports sexagesimal numbers for some reason, using the colon as a separator just like for objects. other things of this nature.
My biggest gripe is that human eyes cannot in fact see invisible coding characters such as tabs and spaces. I cannot abide by python for the same reason.
IIRC, the original reason was to avoid people making custom parsing directives using comments. Then people did shit like “foo”: “[!-- number=5 --]” instead.
I wrote a powershell script to parse some json config to drive it’s automation. I was delighted to discover the built-in powershell ConvertFrom-Json command accepts json with // comments as .jsonc files. So my config files get to be commented.
I hope the programmer(s) who thought to include that find cash laying in the streets everyday and that they never lose socks in the dryer.
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
programmerhumor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.