4 ms·
Yes, XML is a big annoyance. But let me give you a bigger one: Json. XML's saving grace was that it came with good schemas out of the box, so turning something
by hibikir 11y ago
Yes, XML is a big annoyance. But let me give you a bigger one: Json.
XML's saving grace was that it came with good schemas out of the box, so turning something from XML to, say, a Java object, was not very difficult. It wasn't difficult to use a SOAP service without having to do manual serialization work.
Today though, we are using something that has, at best, extremely weak types, and with schema equivalents that are bolted on, rarely used, and end up relying on humans understanding exactly what the data looks like, just for serialization/deserialization. I guess you can live with that easily if you are writing in a language that has really weak types in the first place, as you'd have to read the documentation anyway (What date format is the field using? Better go read about it), but the moment you try to do something even slightly more sturdy, the process is excruciatingly painful.
Heck, even tools like try to "help" document APIs, like swagger, end up with specifications that chill the bones.
It is as if the web was built for and by people that are absolutely allergic to both specification and types: In a more sensible world, we'd get something like: If the RDS is postgres, then the data format is like this, and if it's MySQL, it's like this instead. But what we have out there in the world is big lists of optional fields that will be illegal, or ignored, or who knows what.
I was a big XML hater, back in the days of SOAP, but the more I see how services are defined today, the better the old rust bucket looks.
- rpd9803 11y agoHaha, I've just always thought that if XML was too hard for you, maybe you should stick to graphic design...
- sk5t 11y agoI would argue that JSON wins by the maxim of "worse is better"; its vastly reduced feature set works to repel bad architects' efforts to incorporate horrendous and partially-supported WS-* concepts, external entities, doctypes, crazypants XSDs, and the horrors of XSLT--not that these things are bad in and of themselves, in fact they can be great, but interop can turn into absolute hell. IME if you have the luxury of working purely in .NET, on an updated, common version of WCF, and also nobody on the team goes wild with overdesign, the tooling and the things you can do are pretty great. OTOH testability is questionable, security might be bad, you spend a lot of time finding the right magic incantations to make everything work, and sometimes the tooling breaks in bizarre ways despite good efforts. TLDR I used to be a big fan of XML, have switched to JSON, and probably won't be going back.
- dpark 11y ago> XML's saving grace was that it came with good schemas out of the box, so turning something from XML to, say, a Java object, was not very difficult. Huh? How do you know what types <a><b c="d"><e/></b><b f="g" /><a> has? How do you transform that into a Java object? For that matter, if you manage to turn this into a Java object, how do you know how to transform it back into XML? What members turn into attributes and which turn into sub-elements? Or are you referring to XSD, which showed up years later, is not required, and often not used? Yes, XSD grafts typing onto XML quite effectively, but this is a bolt-on just like the JSON approaches. It just turned out to be a widely-adopted bolt-on.
- elktea 11y agoWho cares what the XML looks like? You import the wsdl and off you go.
- annnnd 11y agoIF it works. Which it almost never does (in my experience: 3 fails out of 3 trials), unless you are using the same SOAP library on both ends.
- eoincathal 11y agoSimilar experiences for me. Needed to spend time tweaking a wsdl so it produced the same behaviour in 2 SOAP webservice endpoints, one using dotNET tooling and the other Java. Worked fine after a bit of fiddling but leaves an uneasy feeling.
- ubu7737 11y ago> XML's saving grace was that it came with good schemas out of the box JSON is inherently "schema-less". So this provides us with no grievance. > something that has, at best, extremely weak types You provide the reader with nothing that indicates that strong-typing is important for JSON use-cases. > schema equivalents that are bolted on, rarely used, and end up relying on humans understanding exactly what the data looks like There are no schemas in JSON.
- tbrownaw 11y agoThere is always a schema. True, json has no formal explicit schema attached to the data. However, there is still the ad-hoc informal schema that's defined by what the code interacting with the data does. Because this tends to be poorly specified and hard to get at, it's rather annoying to work with.
- annnnd 11y ago> I was a big XML hater, back in the days of SOAP, but the more I see how services are defined today, the better the old rust bucket looks You really should try to use SOAP again, you will soon change your mind. I used it a few weeks ago (after about 5 years of peaceful life) and let me tell you - it still sucks. The problem with SOAP is that, even if it is a standard, every $@%#*! library implements it in a slightly different way, leading to incompatibilities. Maybe it was just my luck, but every time I tried to use SOAP I ended up debugging XML envelopes and whatnot. With REST/HTTP + JSON? Just send, receive, parse, do what you want. </rant>