The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I have been using XML for data transmission and for data specification since 2000. What I like most of XML and XSD is that I can define several namespaces for different fields, this way, whenever I get a tag (e.g. <price>), it has implicity the scope of such tag, there are no doubt whether the <price> belongs to a scope or to another because it comes with its namespace (e.g. <price> can be "books" or "pencils"). If you define good XSD files, the XML will be parsed and be XSD-compliant with any language (C#, Java, Python...), serializing the XML documents into objects and viceversa.
[There are other great things of XML that I really like, but it is not the aim of this discussion.]
When I have to deal with personal data or some data regarding "money" (bills, business, purchases...) I always use XSD because I want to map the correct data into the correct field. For other, not sensible, data I use JSON.
Important note: Beware of namespaces, the most common error when parsing is when namespaces are in-lined. Some XML are produced badly and the receiver launches weird errors that make developers eventually hate XML. I think that it can be the reason for your intolerance this morning
Yes, we use XML in my company with some complex schemas. But since the beginning we have used LiquidXML to define the schema and generate the code (C++ and C#), otherwise it would have been a nightmare. But I must admit that it works fine: the process is quick, we can easily manage versioning and performances are good. But don't look at the generated code, it's awful!
In the last developments, we now use Json (manually) but the data structures are less complex so it's not really comparable.
XML can be great, but there is more to know about it than most people realize (namespaces for instance). There is a reason why .NET Core switched back from JSON to XML for projects descriptions...
When done well I think it can be close to the sweet spot between human and machine readability (if you need that). It has comments, and can natively handle many data types that JSON cannot (like dates). If bandwidth is you primary concern then perhaps you should consider binary serialization?
When done bad you get almost any of the OGC Standards[^]...
I have used both XML and JSON over the years.
XML has full and proper support for XSD and great XSL. It also allows really tight security for messaging. Not had the same tightly secure messaging experience with JSON can not completely judge this! Is the a standard for doing it - I don't know.
XML appears to me to be much better able to be validated.
JSON is very quick JSON Schema seem to be quite good but not as tight as XML.
In the world where I used XML with the full security packages around the payloads (of XML) there was signing and encryption - the way to work was to peel the layers of the onion away slowly gaining greater trust as you proceeded into the payload. This works very well for confidential business messaging.
I do enjoy the simplicity of JSON but is it too simple?
I retired after 4 decades in software engineering in 2014.
Though I used XML extensively during my career, I found it more of a nuisance than anything else. XML and JSON merely serve to add layers of software to handle the formats, making them both rather inefficient. And both are text-based.
Similarly comma-delimited data is text based as well without all of the extra meta-data and when encrypted would produce smaller files or data-packets for transmission.
For most situations, one can use comma-delimited data in the same ways as XML with a little ingenuity and without all the extra meta-data.
Sr. Software Engineer
Black Falcon Software, Inc.
My professor said that XML exists because Microsoft was afraid of being sued because JSON was to much like Java. Kid of like the same reason that C# exists. I think he was being sarcastic but am not totally sure. He did show that history of the two and which came first is debatable. Both have roots that run back a long, long time ago.
So many years of programming I have forgotten more languages than I know.
Every big company is afraid of being sued, but I doubt that's the reason. Microsoft would more likely choose a competing solution in order to lock out a competitor. The story doesn't seem "right" but who knows.
The Microsoft of today is a very, very different company than the Microsoft of 2000. (and it makes them better and worse)
My professor said that XML exists because Microsoft was afraid of being sued because JSON was to much like Java
This doesn't hold up, even if only because it seems backwards. If Wikipedia's accurate, work on XML started in 1996, and became a "W3C recommendation" in 1998, while JSON only started showing up in the "early 2000s" (granted, with some references to work starting in 1999 - but it was still very early in its design by then).
And how is JSON in any way "like Java"? One's a data storage file format. The other's a full-blown programming language.
As one of our exercises working in Java we were to take a Json file and convert it to routine that could be compiled in the program. It was to contain data that the program loaded. As I remember from the early 20's it was quite easy.
So many years of programming I have forgotten more languages than I know.
My professor said that XML exists because Microsoft was afraid of being sued because JSON was to much like Java.
Then your professor, by "XML exists", presumably meant "XML did not die" rather than "XML was created".
XML predates the first JSON RFC by ten years. And, XML was in use for several years before it was formally standardized.
I really do not see how Microsoft gets into this. MS certainly neither defined XML nor JSON. I never saw Microsoft as a very active promoter of XML. C# was created by MS. I am not (yet) able to find on the net any documentation of the MS/Sun controversy, but twenty years ago "everybody knew" that C# was a response to Sun not allowing MS to use Java as it wanted. (If my memory is correct, MS wanted to add language features that Sun did not approve of.) So C# is a very different story from XML/Json.
XML syntax borrows a lot from far older formats: Typesetting systems of the late 70s (maybe even older) used the same style bracketed keywords, e.g. to delimit paragraphs and specify paragraph formatting. You can see a selection of such tags e.g. in the 1982 Historical Manuals: Guide to Typesetting at the UKCC[^], at page 14-15.
In the typesetting systems I ever touched, the brackets were displayed as common brackets, but had a different internal representation, and distinct keys on the dedicated terminals. So there was no need for escaping or other special handling of the common brackets (or math smaller/greater than).
I always hated working with XML. JSON is a god send. I had to serialize from JSON to XML for a file upload. It was mandated that way.. not my choice. Anyway I now have an XML Serializer that is stupid simple to use.
Xml wasn't originally written for web service data transfer or serialization/deserialization. It was written by the W3c to replace Html but still be Html-like. Xml is a Mark-up language, hence it has mark-up. Mark-up makes it good for readability by humans but also a standard readable by machines. Xml was then hi-jacked to be used by SOAP web services with serialization/deserialization. Then someone realized that json was better for serialization/deserialization, especially since readability by both humans and machines wasn't necessary, it only needs to be read by machines. JSON also has room for improvement in verbosity and as soon as a good replacement exists, people will say the same things: why json when new-thing is better.