Yeah. Am a developer. But i think, Json is better.
When I was defining markup, it was pretty difficult to decide where to put things: attributes or nested properties. But when done with it, it looks pretty appealing. But parsing xml is horrible. JSON is way better for that
Thats why json is a good alternative with some libraries online
XSLT was amazing!
I find XML is only readable/good and better than JSON in very simple use cases. Otherwise JSON is better for longer and more complicated or complex.
Xnl is really bloated when you have namespaces all over. Like each tag and attribute belongs to a namespaces. When there is only one, no problem. But if there are many... That's one of the most powerful things about XML, when used in conjunction with XSD-s. But at that point is quite a resource-hungry stuff and really not for human eyes anymore...
I've done a ton of SOAP, so a lot of XML. I will say it's not the worst, but a big problem is parsing arrays. When parsing an array in XML, you have to help it along as there is no way to notate an array in XML. JSON is just better in every way
What I can't stand about XML is the use of attributes. There aren't any well known good practices about how to use them properly. That's why I always prefer JSON over XML.
You should link off to those articles.
I agree. I think something like Maven is about as readable as you're going to get with XML. And I'll take XML over something like Gradle, because I don't really like the way Gradle and other Groovy-based DSLs blur the line between declarative and imperative. I might even take XML over YAML for large config files in certain cases. If I'm on a remote server or something like that without access to a good editor with proper code folding, it's gonna be easier to find and differentiate child, sibling, and parent nodes. Especially if the YAML has 2 space indenting.
Pain. XML is pain.
Fun fact for js (which has actually nothing to with xml but with json instead, though I don't know when I'm gonna find a similar video to talk about this), you can actually get a bug in js which is comparable to pointer bugs in C/C++ for example and it makes js do some undefined behaviour: So basically, if you make an object in js, be it a class instance or self made, plain object, you can't have two keys in it with the same name. JS gives you an error if you try to do this and this is great, that shouldn't happen, like ever. HOWEVER Json DOES allow same name keys in an object for whatever reason. And JS also allows these JSON objects to be loaded and parsed into JS Objects from a Json file. You won't get any errors whatsoever. So what will happen? You now have a JS object that contains a duplicate key and if you try to write to it, strange things will happen. Values in between will get overwritten or corrupted (imagine you have a field called age, the first field in the obiect, then some other fields and at position 6 you have age again). Wrong values will be written to, fields will change data types or get interpreted as a different data type, you'll get fields suddenly copying itself in name and value and so on. A glitch I've encountered myself in my job and it still amazes me to this day
Screw XML its so uneditable. Have you ever tried forking an XML based GUI program? Its horrible.
I love XML ❤ for making PDFs thru Adobe SDK very easy better than json
The problem is that there isn't much that you can do with XML that you can't do with JSON. The line between an attribute and a field is very, very thin to the point it often feels arbitrary whether you choose one or the other. This makes it very common in the business world to find services and products that use stupid / needlessly painful XML schemas that you now have to deal with.
TOML >> YAML > JSON > XML
I pray for my comrades who had to use SOAP at their jobs. I have experienced that while working on a legacy project. XML, WSDL, XSLT... had nightmares for a longgg time. I hate SOAP and everything that comes with it.
XML really IS horrible. In the real world, you don't define such a clean and short schema yourself - one is often reliant on nonsensical schemas, mixed namespaces, strict data types, etc., all in a format that is bloated by duplicate tags for open and close, and consists to about 25-40% in size of whitespace. For 80% of use cases, an .INI file would be sufficient, while JSON would cover at least 99%.
nice editing at the start
@crimsondragon2677