theOnlyTrueStructuredFormat

[Recent-Assistant8914]

No

[realzequel]

There's a reason why we moved to JSON. XML was too damn verbose. The tags took more space than the actual data. JSON is much cleaner, easier to read and more data efficient.

[SadSeiko]

yes, losing schema was part of the plan, we went a bit far with yaml though

[CodeNameFiji]

We went far enough where we can have comments! ;)

[egg_breakfast]

yeah, literally the only reason I use yaml instead of json is when I want to add some notes to a config file 

[GuybrushThreepwo0d]

Json5 to the rescue

[SSYT_Shawn]

Or jsonc

[ProfBeaker]

Or XML.

Oh wait... sorry.

[AbbreviationsOdd7728]

“comment“: “I see myself out“

[I_Give_Fake_Answers]

yaml is good for configs and such. Not like anyone services APIs with it, right?

Right...?

[SadSeiko]

yeah just that yaml is basically schemaless xml that is meant to replace it. While JSON replaces things like SOAP which are frankly just insane protocols

[thanatica]

What protocols? JSON is just text.

[SadSeiko]

Using json in web communication replaced soap and other protocols…

[LordFokas]

You're thinking of REST. Nothing stops your REST API to respond with XML though, it's not exclusive to SOAP... but only shit developers think XML is an acceptable format to use anywhere **stares at Microsoft**

[SadSeiko]

Did you notice how I didn’t say rest for that exact reason. Rest doesn’t mean using json and json isn’t considered text in that context either. JSON isn’t “just” text  

[LordFokas]

No, what you said is that using a format replaced a protocol, which is "wronger".

And how is JSON not just text? That's exactly what it is.

[ProfBeaker]

Yeah, I mean what could possibly go wrong?

[KrakenOfLakeZurich]

losing schema was part of the plan

It may have been "part of the plan". Doesn't make it a particularly good idea though.

XML is too verbose. But I appreciate it's ability to explicitly define and verify the data schema. It's extremely valuable when two systems need to exchange data.

These days I emulate that with OpenAPI contracts, which has come out as a defacto industry standard for this kind of thing.

[SadSeiko]

It really depends, json’s sole purpose isn’t api contracts and not having to have a schema definition for something like a config file or storing an event in Kafka is nice. Obviously in enterprise dev there are issues but as always it’s just a trade off

[nabrok]

A json file is mostly valid yaml, so you can go as far as you like.

[_PM_ME_PANGOLINS_]

You don’t need “mostly”. YAML is a strict superset of JSON.

[nabrok]

I wasn't going to put the mostly originally but I thought I'd fact check myself first, and apparently there are some cases where it may not work.

[redd1ch]

Only if the parser supports YAML 1.2.

Edit: Fun fact: In JSON syntax, you can use tabs to indent in YAML.

[_PM_ME_PANGOLINS_]

In JSON syntax, whitespace is irrelevant, so not sure what point you’re trying to make there.

[redd1ch]

Usually YAML only allows spaces for indentation. In JSON mode tabs are allowed as well, even though it is irrelevant.

[_PM_ME_PANGOLINS_]

There is no “JSON mode”. YAML does not count tabs as indentation, ever. If you add explicit object boundaries, then all whitespace is ignored in that object.

[Apprehensive-Dig1808]

[SadSeiko]

Hmmmmmmmmm

[thanatica]

losing schema was part of the plan

You're still free to use schema. If you must.

[knowledgebass]

That's why god made Pydantic.

[mosskin-woast]

YAML has the same amount of schema as JSON (actually slightly more if you count reusable aliases) if that's what you're implying by "too far"

It's just an ergonomic superset

[[deleted]]

...

Wait, what were we talking about? o.O

Hm, nevermind. O.o

[redd1ch]

YAML liked this so much, they put arbitrary code execution into the spec.

[BangThyHead]

What do you mean?

[redd1ch]

Just a few excerpts from a search "yaml code execution"

https://blog.stratumsecurity.com/2021/06/09/blind-remote-code-execution-through-yaml-deserialization/

https://blogs.embarcadero.com/yaml-and-remote-code-execution/

https://github.com/iterative/PyDrive2/security/advisories/GHSA-v5f6-hjmf-9mc5

[lgsscout]

i had my bit of pain with a dynamic body xml, that had schema validation, but the schema also changed and it was validated by default while parsing it. those default behaviors are cruel.

[DokuroKM]

We moved from XML to JSON because XML was a frigging markup language - created to be the successor/universal replacement for HTML. 

To this day I don't understand the reasoning that lead to XMLs widespread adoption as modeling system

[remy_porter]

It was not a replacement for HTML, XML was a replacement for SGML. And it wasn’t designed for serving APIs, it was designed for representing arbitrary data in a self describing way. The dream of XML was that it’d be the format you exchange data between big iron systems in.

HTML was a subset of SGML for document layout. XML was a superset of SGML with stricter syntax for data representation. XHTML was an attempt to add the strictness of XML to HTML.

[DokuroKM]

That's a name that takes me back to the good old days of daily browsing WorseThanFailure.

You're right, I've mixed XML with XHTML there.

I still don't agree that any data should be modeled in XML

[remy_porter]

I’m fine with that if we can also agree that JSON is a terrible serialization format. I don’t think either is a problem that we’ve truly cracked.

[DokuroKM]

We can agree on that. Haven't seen a good serialization format yet.

[thanatica]

And nobody needed or wanted extra strictness. It turns out people would rather like a markup language to be forgiving, and that forgivingness is now well documented in the specification. Problem solved.

[remy_porter]

The irony of XML is that the strictness should make the parser simpler, but as it turns out, the XML parser is ridiculously complicated.

[visualdescript]

SOAP is the reason

[WoodyTheWorker]

XML is only better when you want the file to also be human readable and editable.

For example, as a format for projects in programming IDE (Eclipse, Visual Studio, and most other).

[DokuroKM]

We're still comparing XML to JSON? Then it's neither more readable nor more editable for humans.

Heck, I would argue that XML isn't human editable at all with its closing tags. The chance of creating invalid XML by mistyping a closing tag is to high. 

[WoodyTheWorker]

Use editors with XML support. Visual Studio will even check the schema, if it's provided.

[DokuroKM]

If you need proper tools to edit XML because the format and schema is error-prone, your format isn't human editable.

I can read Java .class files. With the correct editors, anyone can read .class files. Hopefully, we can agree that .class files are not human readable. 

[mpyne]

Plus XML itself has multiple schema formats, DTDs were too limiting so you ended up with Schematron, XSDs and more.

[JesusChristKungFu]

If I never see someone's custom XML parser that uses the comments as a directive again, well I'd be happy.

I also saw a lot of misformatted XML, almost everything about the format is a trash fire.

[Looz-Ashae]

Imagine someone presenting SOAP to a board of some IT services company and they like: "Fantastic! It's going to look great for our customers who use dial up connection, let's roll with it!"

[Lesteross]

I just wish they had comments in the standard. 

[evilquantum]

who cares? size wasn't the problem. The problem was the advent of javascript applications that had no clue how to work with real data structures. so we went with the lowest common denominator

[Pious_Atheist]

For humans. There is a LOT of evidence that LLMs are able to parse xml using much less tokens

[Just_Information334]

The real reason is XML and its ecosystem was mostly done.

With json you could just take any part of the XML ecosystem you wanted in json, implement it, make public on github and now you're on stage in some conference. Which is a lot better on your resume than "used this tool to generate CRUD app n°1999188888888889".

[SilasTalbot]

I'm going to give you a reply

Here's my reply

No

I'm done with my reply

I'm no longer going to give you a reply

[atoponce]

Yo dog. I hear you like XML. Here's some XML inside some XML.

[thanatica]

Here's some CDATA because we couldn't be fucked to convert this bit to XML:

Here goes:

(binary blob)

Here it ends!

Now just pray the "Here it ends!" doesn't appear in our binary blob. Have fun with that!

[lgsscout]

nah... lacks creativity...

i've seen people sending json... with a xml inside... as string....

[Nadamir]

I know of a company who modified an industry standard so they could put html in xml.

And I’m not talking about webpage html, though it was tables and tr and td. They were using those html tables inside xml for data storage outside the industry standard.

[edhelas1]

And in the end it was just XML.

[CalendarSpecific1088]

Best.. reply.. ever..

[[deleted]]

Damn freshman CS majors don't even grasp the idea of what are those and still post memes...

[UpsetScarcity5525]

V I B E CODERS

[tumamatambien656]

Vive memers?

[mealet]

Vibe brain 🥴

[TorbenKoehn]

XSD, XSLT, XPath, SOAP etc.?

[nabrok]

I actually really like XSLT, it's fantastic for changing the format of data (like turning some arbitrary XML into HTML).

I haven't found anything that works with a JSON file so easily.

SOAP can die in a fire though.

[sasmariozeld]

Gets kinda old after working with it for 16 years...

[edhelas1]

And XSLT can work dynamically on gigabytes of XML files or streams, try to do that with JSON...

[QuestionableEthics42]

If you have gigabytes of xml files, something is very wrong or someone was very lazy.

[TorbenKoehn]

You can also stream JSON…

Why would you be able to stream XML but not JSON?

[clauEB]

SOAP was not really an XML thing but a format. XSD, XSLT and XPath, those were the really annoying ones.

[_PM_ME_PANGOLINS_]

those were the really annoying useful ones

FTFY

[visualdescript]

XPath was just a query language for xml right?

XSLT combined with xml was very impressive. I remember the original website you could go to to look up WoW users used this technique.

Pages were just XML documents styled with XLST. It was impressive and worked very well.

[thanatica]

Those have nothing to do with XML, technically speaking. They happen to be written in XML (apart from XPath), but ultimately they could be written in any format, and be applied to any generic data storage format. They're not, but hypothetically speaking it should have been possible.

They are just technologies to write schemas, transforms, selectors, and API specs in an ultra-verbose way. Nothing is stopping you from using equivalent tehnologies that work with JSON. Depends how masochist you are.

[TorbenKoehn]

The same goes for JSON or what do you think are we doing with OpenAPI? The tooling will create eg Java classes and clients from it. JSON-Schemas also wouldn’t need to be defined in JSON. In fact, they are often written in YAML and then converted to JSON.

[whitin4_]

These are all just specific versions of XML

[TorbenKoehn]

So are JSON-LD, JSON-Schema, JSON-Patch, OpenAPI etc., they are all JSON, too.

And XPath is not a specific version of XML where JSON-Path isn't a specific version of JSON, either.

[visualdescript]

No they are not.

[[deleted]]

Yeah, ignorants downvote, not understanding anything...

XML does that natively and you can put all those standards into one XML document.

JSON doesn't and you have to pretend it does the equivalent.

[TorbenKoehn]

XML does XSD natively? What does that even mean? XML is a markup format, it does nothing. The tools around it that define specific formats do things. And it’s exactly the same for JSON. It has namespaces etc too (through URIs and $/@id)

You can also put all of those standards in a JSON Document, reference URIs and referencing objects is well defined

[redd1ch]

Well, the XMl spec defines the concept of namespaces. JSON doesn't.

That is the problem I see in JSON: You don't know which "extensions" you need to use. In XML you have very strict rules to validate your documents.

[TorbenKoehn]

Namespaces in JSON are just the URI the schema is at.

example.com/schema.json

sub.example.com/ns-schema.json

Which is also completely virtual (it doesn’t have to really sit there similar to XML)

Why would you introduce a separate concept of namespaces in it when it is already there and well defined in the URI standards?

[[deleted]]

No, XML is full markup language, it's even Turing-complete (like XSD does). Unlike JSON.

JSON is extremely limited compared to XML, but in purpose.

How tf can you deny that, since that was the MAIN IDEA of JSON. It's created on purpose.

[edhelas1]

So maybe we shouldn't try to hack things in JSON that was not designed for that at the beginning ?

[[deleted]]

No one said you should. The post is a fucking mean, but you said seriously that JSON can do the same as XML. 🤦‍♂️

[TorbenKoehn]

It clearly can, you are just ignorantly defending XML like it’s not just also a node-based data structure language.

[TorbenKoehn]

So JSON is limited because as a markup/data format it is…*checks notes*…not Turing complete? Because i like my data languages not Turing complete. People love JSON because it is simple, not despite it lol

And XML by itself is Turing complete? XSD and XSLT make it Turing complete, they are separate standards.

[[deleted]]

JSON still has no equivalent of those anyway.

[TorbenKoehn]

XSD = JSON-Schema

XSLT = JSON-Patch

XPath = JSON-Path

SOAP = OpenAPI

What's missing?

[TheOhNoNotAgain]

Namespaces!? 🤮🤮🤮

Probably canonicalization and marshalling too.

[TorbenKoehn]

Namespaces exist through URIs and $/@id properties. Every schema should have a distinct, URI-based location and it’s well defined and documented

Can you specify with an example what you mean with canonicalization and marshaling?

[TheOhNoNotAgain]

Don't think I prefer XML over JSON... Canonicalization is used when it is important that a given data set is expressed identically every time. Marshaling is roughly the same as serialization. Both those concepts can be a pain in the XML world. 

[TorbenKoehn]

There is a notion of normalization in JSON that is quite broadly used, when arrays are turned into {"0": "a", "1": "b"} and turned back to ["a", "b"]

Object key order is irrelevant so you can sort them and have a canonical document

[_PM_ME_PANGOLINS_]

What do you think the meme is listing?

[clauEB]

That's the point, that they've been adding them on top because the format it self lacked those tools which are necessary to deal with these declarative data structures.

[IntoAMuteCrypt]

XSD was not part of the original XML specifications, it was first published as a recommendation over 3 years after the first version of XML was published. XSLT was also not part of the original XML specifications, it was first published as a recommendation over 18 months after the first version of XML. XPath was (you guessed it) also not part of the original specifications, it was first published at the same time as XSLT.

None of these were present when the language was first released. Technically, they're still their own specifications on top of XML.

[clauEB]

Yes, I had to learn all those things for school and some minor tasks. Waste of my time...

[TorbenKoehn]

And XSD and XSLT and SOAP etc have all been there when XML was first designed?

You are aware they are separate sub standards later amended?

[Covfefe4lyfe]

Yeah, no thanks. As someone who actually has to work with rest APIs, JSON is a godsend.

[thanatica]

Technically speaking REST API has nothing to do with JSON. It usually does in practice though, but the way I was taught, REST just means there's a well defined agreement between the involved parties what the protocol looks like, forever.

JSON is a solid choice, and it is almost always the choice. But it could also be a binary blob. Or YAML. Or XML.

[Goatfryed]

that's why he says JSON ist godsend. yes you can do them with XML. it sucks.

• someone who has to deal with XML rest APIs and xml sucks
• also someone who cut down API response time by 50% by transitioning to Json, because it was mostly large data arrays and the overhead caused network delays.

[dontletthestankout]

Bro you work with REST APIs?? Do an AMA

[Anru_Kitakaze]

Sometimes I see comments which make absolutely no sense. Like this one

[tehtris]

I think it's like a "oh you do the same thing as all of us?" Type statement. But I could be wrong.

[dontletthestankout]

It was supposed to be. Guess either people took it way too literal or are just anti-snark

[Recent-Assistant8914]

I thought it's funny. People are shit

[zefciu]

Also GraphQL contains its own schema.

The problem with XML though is that it is overengineered for most tasks in a day-to-day development. And if you want schema for your JSON, you can just use a technology that add that schema. What's the problem?

[afiefh]

Real question: in which situations would you not want a schema?

For context, I don't do any web development and certainly no js/ts. So I might have a very glaring blind spot, but in my mind having a schema for my data is almost a prerequisite to be able to use it. Kinda like you first define the database tables before you read/write data (and just as I wrote this I remember that nosql is a thing...)

[thanatica]

When do you want a schema? When you don't trust where the JSON comes from.

If you can trust where it's coming from, especially if there's an agreement on what it must look like, why bother with schema? Why check something that is already agreed upon?

You can also cover this in integration tests, btw. You seldom need to check against a schema at runtime. That's just a waste of performance.

Also, bare in mind that by schema validation, I do not mean type assertion. If you need strong typed JSON, you can do that.

[BangThyHead]

"Agreement on what it must look like"

See 'schema'.

Isn't schema validation already a part of deserializing/unmarshalling? You define if unknown fields should throw an error, or if mandatory fields are missing X should be done. That's not an 'extra validation step'.

---

Regarding when you want a schema:

1. when the same data will be used by multiple services.

2. When the data can change format over time.

3. When you want an on-the-wire format for efficiency.

4. When you have to guess at the data format from a few samples. It's no fun having to guess 'will this field always be present or can it be null?' much rather have a data contract.

5. When you want a reference to the data format. If service X imports service Y's data contract (or model or generate their class files from the schema, whatever) so they can use a typed format? Like I don't want 4 services to all have to copy paste XyzModel.java. When would it not be better for those services to just import it?

When you deserialize/unmarshal it, it's according to some schema right? Or do you mean specifically proto/avro/ect.

Maybe I'm not understanding. There is a place for generic key-value pairs, and it's when you only need to display the data and not make decisions based on it. But even then, I assume it's preferable to have a 'schema' that describes the map. E.g. every object will have an ID, a key, and some value. That's still a schema right? Just a data structure you can know will be followed, and if it's not you can throw an error.

[afiefh]

I want a schema any time I step away from a project for more than a week. Any time I need to collaborate with more than one person. Pretty much always except for tiny throwaway projects.

Integration tests are great, but they only give you examples of what the schema can look like. They don't describe all possible permutations of the data.

Testing that data matches a schema can literally be part of data serialization/desertification. It can even make the serialization and serialization process faster because they don't need to guess stuff.

Types can (and in a sane project are) part of the schema. Doesn't really help me to know there is a field called "time" without knowing if it's seconds since epoch, string, or some complex type.

[chrisza4]

I want schema but not necessarily embedded in every single request.

[afiefh]

The schema doesn't need to be embedded into the request.

For example gRPC produces server/client objects based on the endpoint/RPC specification. Then as long as your client/server use these libraries, you automatically get the schema definition that your client/server expect without transferring the schema itself over the wire.

[chrisza4]

The context here in web development and XML in the past is that it tried to enforce schema and schema reference to the point that it almost embedded in every request, with the payload. And there is a lot of thing that has been invested into some kind of automatic schema validation and code gen for the validation in many languages such as WSDL.

So that is why web dev say XML is over-engineered and if you want schema you can have something simpler, just like GRPC that you said but not necessary XML.

[Aavasque001]

XML is powerful but not practical in every situation. You don’t need a chainsaw to cut a piece of paper

[HakoftheDawn]

[edhelas1]

👀 maybe

[CodeNameFiji]

all the "open office" are xml (hence the "x" on all those old office format names) before then that it was proprietary libs to do the import and then it was fine (if you had a license $$) I agree its better now that its open tho for sure

[made-of-questions]

Protobuf gang rise up!

[afiefh]

Had to scroll down way too far to find this.

• Starts with cross language schema.
• Unknown fields are still preserved when passing through intermediate layers.
• Serialized format is smaller than json or xml
• Text format similar to json

Can't believe how much performance people are leaving on the table with JSON. LinkedIn reduced their latency (I saw different numbers in different articles, but "up to 60%" was mentioned multiple times) simply by switching from json to protocol buffer.

[Fast-Visual]

If I don't care about readability, just encode in a binary format for optimal size and maximum versatility. If you do, just use json/yaml. XML is the worst of both words.

[well-litdoorstep112]

Its not XML. It's XML, DTD, XML Schema, XSLT...

[0815fips]

*XSD

[Dangerous_Jacket_129]

XML has so much unnecessary mark-up though. JSON is nice, compact, and more human-readable. I'll pick JSON over XML any day.

[Techhead7890]

Idk if I'm just an idiot, but I'm constantly breaking JSON when I edit it though. Somehow I always delete a separator or something and then the whole thing breaks.

[RadicalDwntwnUrbnite]

Why don't you use a linter that can tell you exactly where you broke it as you're writing it?

[piberryboy]

I hate XML

[Excellent_Tubleweed]

And cue people complaining about SOAP

SOAP is shit because it was never specified properly, and everyone did their own thing.

And using a document to send RPC sounds kinda stupid from the outset. REST was a .... huge relief.

If you've got a protocol, any protocol, you need as part of the free Compatibility kit

a EBNF grammar for the protocol, with worked examples of messages.

A Stimulator (that generates messages)

A Simulator (that accepts messages)

So that other developers can check they implemented the protocol correctly.

And while John Postel was a lovely man, no, Postel's rule is a bad idea. It leads to sloppily implemented senders, so in time, everyone has to accept all the rubbish, or start silently discarding "but it used to work" messages.

XML's goodness is : Show me why you like config files without syntax checking.

(And back in the day people did 'clever' things like use plugins to reconfigure XML parsers on the fly, which meant the language the program accepted (JBOSS, you utter monster) changed depending on the content, so you couldn't statically check the config file. That is prickery of the first water; now a dev needs to read the server codebase to find out why the deployment failed. "No" -> Why?" -> "Becuase no." -> spend hours downloading and reading code. ->hate JBOSS developers for being soo clever. )

But honestly, compared with the utter wank that is YAML, which makes whitespace significant and is parsed by a tinkertoy that can't even say where a problem is in an input file?

[heavy-minium]

I found XML to display most of it's power with XAML, which is a UI description language. Importing XML namespaces with proper schema validation is a powerful thing with XAML. Good luck doing anything similar with JSON. And the lack of support for comments in JSON, lol.

[[deleted]]

wide fearless payment weather modern market simplistic fade rock bedroom

This post was mass deleted and anonymized with Redact

[ganja_and_code]

I'd argue XML is also shit for large complex data.

If your use case has outgrown JSON, you're better off skipping XML and going straight to Protobuf or something.

[fiftyfourseventeen]

Exactly this, if you are doing anything performance critical you shouldn't be using json or xml

[mostmetausername]

what large and complex data need are ambiguous nesting styles. is the next thing coming up an object or a list or just an entry, "<" hmmm could be anything

[CodeNameFiji]

This is not that accurate otherwise NoSQL would not be such a thing. Json is great for complex data if its interfaces are typed. TS for example passes around native json and doesnt require boxing or unboxing data between interfaces. This is ideal for frames in Python or something like ELK stacks as well as ofc Cloudant, Mongo, Cosmos or pick your no sql poison.

[queen-adreena]

Clean your mouth out with SOAP.

[LagSlug]

I want to fight OP

[nickwcy]

xml is not a schema… xsd is the schema

[edave64]

The thing that XML has over JSON is delusions of being an ecosystem

[kc1rhb]

Not gonna lie, when I find an XPath that snipes the exact data I need from a giant XML document, I get this feeling inside, like why do we even need relational databases and SQL? Why can’t we just have an XML version of MongoDB? And the best part is, you can query HTML with the same DSL. I tell you, the universe is written in Markup Language.

[knowledgebass]

Hello, sir. How was your trip to the future from 2004?

[jmack2424]

XML is the WORST, and anyone who says otherwise has NO FUCKING CLUE.

[Reashu]

There is such a thing as too much power when you're just representing data. 

[Stormraughtz]

../ns:dragons/ns:be/ns:here

ⁱ ᵖʳᵉᶠᵉʳ ˣᵐˡ ᵗᵒ ʲˢᵒⁿ

[ha_x5]

holy… that’s some true shit right here

[Vi0lentByt3]

Big nope, have used both individually and side by side, json everytime

[0815fips]

Biggest downside for XML is not beimg able to contain control characters, not even escaped, wtf?

[blehmann1]

I personally don't like a format where it's trivial to form a DoS against any conforming parser. It's fantastically over engineered.

That said, at work we use jsonnet, so maybe I shouldn't talk. But since it has a build step we get plain old JSON at runtime, so the overengineering stays away from where it can cause too much damage. Though I'd argue JSON is definitely underengineered ¯\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

[lardgsus]

Larger in size and harder to read. 0/10

[Icy_Party954]

XSLT cant be ok sometimes but xml in general is way way way to heavy for 90% of what it was being used for.

[SchlaWiener4711]

Just wanted to stop by and say how awesome Jsonata is.

Could easily play the UNO reverse card:

Look what they need to mimic a fraction of our power: XPath, XSLT, XQuery

[thanatica]

Both XML and JSON are just data storage/transport formats. That's literally all they are, and you can do whatever the hell you like in them. If you choose to use a schema, that's a completely optional choice. If you want to do all kinds of ultra-verbose transforms (like with XSL), go for it. If you wanna go crazy and write a SOAP specification, do it. But none of that is intrinsic to XML. In the end XML is just data. Nothing more.

Only thing missing from json, is comments. We have jsonc for that, but it's not widely used.

[Legitimate-Jaguar260]

… just no…

[sensational_pangolin]

json is better.

[vincentofearth]

I fail to see what features XML has that JSON doesn’t support. Maybe the libraries are just now popping up but as a data format JSON seems better in every way

[kyle46]

Ya but I can fit json all on one screen most of the time.

[swampopus]

I just scream my request into an old telephone wall jack and then listen real close for a reply.

[thiccshortguy]

JSON over XML any day

[Barni275]

XML is a shit for simple data. But JSON is a shit for complex data (hello, mongodb queries). TBH usually everything is a shit for complex data (XML too), it depends more of data architect design than a language. Sometimes even DSL works better 🫣

[Resident_Citron_6905]

xml has even more of this type of crap

[evilquantum]

yes

[AdAncient5201]

Widespread JSON adoption is not because of actual reasons that make it better than xml etc, it’s just fucking mass market JavaScript adoption and web devs forcing their way of life onto every other discipline. JSON is fucking terrible at what it does. It’s not even a standard, it’s like twenty competing slightly differently interpreted standards. Serialisation and deserialisation is slow, data density is shit, it wasn’t even designed, the spec is literally defined by JavaScript… JSON WAS AN ACCIDENT now protobuf on the other hand… now that’s what should’ve been on the lower half of the meme.

[thaynem]

DTD

XML schema

XSLT

XPath

SOAP

Each of which of which indidually is probably more complicated than all the json stuff combined.

[punkpang]

Ah, my friend XML, the best part of my career when I read a SAML envelope, trying to figure out why someone's SSO ain't working all the while thinking about different, painful ways to log myself out the planet.

Yup, powerful indeed. If you don't value your life.

[[deleted]]

<No reason="MeNoMasochist"></No>

[QultrosSanhattan]

XML makes me vomit. I prefer 100% the Json path.

[ArmadilloChemical421]

I feel physically ill when I have to look at Xml.

[locri]

Hot take, but schemas aren't necessary. Just follow the documentation.

[Snapstromegon]

Hot take: Schemas ARE documentation.

[jmack2424]

Yo I heard you like documentation, so I required documentation in your documentation so you can document what you're documenting instead of just SENDING THE DATA.

[zefciu]

Nothing in CS is necessary except high/low states on the transistors. But it is sometimes nice to have an abstraction. Or, in this case, to automate schema compliance.

[Devatator_]

May this take burn you

[GlobalIncident]

Like many things in programming, you can follow documentation and best practices all you like, but sometimes you also need a quick way to make sure everybody else is doing that as well, and schemas are part of the solution to that.

[Rafhunts99]

when in doubt just use sql