SOAP requires reading a manual before you get started, but so do the frameworks that try to replace it. APIs are APIs, you rarely need to manually access any of the endpoints unless the backend doesn’t stick to the rules (and what good do any alternatives provide if that happens?) or your language of choice somehow still lacks code generators for WSDL files.

OpenAPI/Swagger is just SOAP reincarnate. The code generators seem to be a bit more modern, but that’s about it really.

That’s not a comment, that’s a field. There’s a reason var comment = "Increments i by 1" isn’t how you comment in any programs.

Please don’t. If you need something like json but with comments, then use YAML or TOML. Those formats are designed to be human-readable by default, json is better suited for interchanging information between different pieces of software. And if you really need comments inside JSON, then find a parser that supports // or /* */ syntax.

XSD and XSLT files alone can replace half the JSON applications I’ve seen. I can see why it’s easier to take the barebones JSON notation and reinvent the wheel, but those tiny programs are the “Excel+VBA” of web applications.

And don’t forget about namespaces. Look at formats like HAL and ODATA that try to add HATEOAS onto JSON.

There’s comments in the specs and a bunch of parsers that actually inore //

On one hand I agree, on the other hand I just know that some people would immediately abuse it and put relevant data into comments.

Most web frameworks contain code to exchange JSON over XMLHttpRequest for a reason. XML is and always has been a data transfer format as well as a file format. JSON is, too. The amount of config.jsons I’ve had to mess with…

but using XML to communicate between your app’s frontend and backend wouldn’t be either

I don’t see why not? The entrypoint of web frontends is sent as HTML already. I guess that’s based on SGML, XML’s weird and broken cousin. Outputting XML is just a matter of configuring whatever model serialiser from JSON to XML.

There are a few good arguments against XML, but those also work against JSON.

We were using XML for that before JSON.

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

TOML or bust

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.

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.

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>

Unironically.

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

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.

This is what happens when people make content for points.

OP already admitted he made it up.

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

perplexity.ai

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

fake

Ah… Too bad (: