deleted by creator

[This comment has been deleted by an automated system]

We were using XML for that before JSON.

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.

[This comment has been deleted by an automated system]

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.

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.

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

perplexity.ai

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

fake

Ah… Too bad (:

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

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? 🤮

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.

JSON not supporting comments is a human rights violation

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!

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.

Unironically.

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

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>

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.

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

YAML

To each their own indeed.

;)

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.

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.

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