11 ms·
XML is well regarded in the enterprise and languages like JAVA, C#, and VB.NET handle is spectacularly as an exchange format. I think it's bad reputation comes
by cptskippy 10y ago
XML is well regarded in the enterprise and languages like JAVA, C#, and VB.NET handle is spectacularly as an exchange format.
I think it's bad reputation comes from anyone not using an enterprise language because the support just isn't there.
I recall working with a partner who we were doing an identity federation with. Our system was using WS-Trust which is a SOAP/XML protocol. It wasn't ideal but everyone seemed to support it ok. These guys were cutting edge though and used Ruby on Rails.
No support for the protocol wasn't a huge deal, just means you have to craft your XML for your SOAP calls yourself. But at the time we were doing this, RoR didn't have SOAP or XML libraries. They had to write everything from the ground up. It sucked for me and I was just fielding rudimentary questions, I can't imagine how painful it must have been for them.
- chrisseaton 10y agoWhat do you think JAVA stands for? It's not an abbreviation. It's the name of an island and it's just 'Java'.
- qwertyuiop924 10y agoWell, XML is complicated, so it's hard to build support for, and it's verbose, so it's heavy on the wire. Frankly, I think JSON is a better format in most contexts.
- barrkel 10y agoThe biggest problem with XML is that it's a node labeled tree that makes the schema choice between leaf node and attribute for scalar data almost arbitrary, whereas JSON is an edge labeled tree without the same choice. Most programming languages use edge labeled graphs for in memory data structures, so the semantic distance is lower with JSON.
- beagle3 10y agoIndeed. Furthermore, JSON readily differentiates between a single element {a: 'hello'} and a vector with one element {b: ['hello']}, as do most programming languages. XML does not, which leads to weird constructs like <Names><Name>a</Name></Names> to indicate that more than one name is possible. (Except .. if you actually use a schema with your XML parser, that indicates more than one is possible. But almost no one does). JSON also differentiates numbers from strings, etc. As a result, in my experience, JSON tends to be more robust in real world use - even when a schema is available.
- marktangotango 10y agoGreat explanation, I'd never heard it put that way before, thanks!
- qwertyuiop924 10y agoIndeed. Even translating to Lisp, which has closer datastructures than most languages, the XML is translated to an edge-labeled tree.
- nialo 10y agoCan you explain what you mean by JSON being an edge labeled tree in more detail? I don't understand and would really like to.
- zachrose 10y agoTaking a stab at this... Let's say we have a dog who has four paws. In XML: <dog> <paw health="ok"> <paw health="ok"> <paw health="ok"> <paw health="ok"> </dog> In JSON: { "paws": [ { "health": "ok" }, { "health": "ok" }, { "health": "ok" }, { "health": "ok" }, ] } I think what the GP is getting at is that JSON is always describing the relationships between a thing and another thing, rarely the things themselves. In the JSON version, for example, it can be assumed that an object in the "paws" array is a paw. This example is sort of a straw man. The JSON version could be wrapped with { "dog": {...} } and the individual XML paws could be wrapped in a <paws> element. But in any case, JSON doesn't need you to give an explicitly label the type of each paw, just what they belong to and what's known about them.
- einhverfr 10y agoXML is very often the least bad format (compared with ASN.1, JSON, X12 EDI, CSV, and other interchange formats), particularly when dealing with statically typed languages. XML is a horrid chimera of SGML but at least it is both human readable, subject to machine validation, and gets the job done.
- cptskippy 10y agoOh EDI... you made me shudder.
- wtbob 10y ago> I think it's bad reputation comes from anyone not using an enterprise language because the support just isn't there. On the contrary, I think that XML's bad reputation comes from the fact that it is <adverbial-particle modifies="#123">so</adverbial-particle> <adverb id="123">incredibly</adverb> <adjective>verbose</adjective>. Also, the whole child/attribute dichotomy is a huge, huge mistake. I've been recently dealing with the XDG Menu Specification, and it contains a child/attribute design failure, one which would have been far less likely in a less-arcane format. XML is not bad at making markup languages (and indeed, in those languages attributes make sense); it is poor at making data-transfer languages. JSON has become popular because a lot of bad programmers saw nothing wrong with calling eval on untrusted input (before JSON.parse was available). It's still more verbose than a data transfer format should be, and people default to using unordered hashes instead of ordered key-value pairs, so it's not ideal. The best human-readable data transfer format is probably canonical S-expressions; the best binary format would probably be ASN.1, were it not so incredibly arcane. As it is, maybe protobufs are a good binary compromise?
- djur 10y agoRuby has had an included XML library since before Rails was released. soap4r is older than Rails too. I wrote my share of clients for SOAP services back then. soap4r wasn't fun to use but it mostly worked. If the service was really simple (a single call and response, for instance) it was sometimes more expedient to put together the request yourself. When Savon came out 6-7 years ago it was a huge relief. Luckily, by that point, I was seeing a lot less SOAP. But even with Savon, the experience was only lifted to "not awful", never to "wow, I'm glad they used SOAP, this is so easy."
- saurik 10y agoMy experience with early Ruby XML parsers is that they were all "how hard can this be?" hacks someone did over a weekend by people who didn't really use XML or understand the ecosystem of specifiations and thereby barely worked and often didn't support fundamental things like namespaces correctly. It took away everything which made XML powerful and left you with something that was often even finicky.
- flomo 10y agoYeah, I worked on a Rails 1.x app which integrated with an xml feed. IIRC, the options were a library that used regexes internally and had horrible performance (but might have been fine for rss feeds), and another library which wrapped a C library and used callbacks[1]. Definitely was a huge pain point and probably was a mistake for me to use the latest hep environment for that app, but for the rest of Rails it might have been worth it. [1] I think it might have been http://www.yoshidam.net/Ruby.html#xmlparser http://www.yoshidam.net/Ruby.html#xmlparser
- deleted 10y ago[deleted]
- ambrop7 10y agoSome time back I needed to generate an XML file in a Java web application. I attempted to figure out how to do it "right". The only "special" requirement was that it is formatted in a readable way. So I was figuring out the Java XML stuff (don't remember what that was exactly, probably standard). But at some point the timeout in my brain kicked in, and I just wrote a loop generating the XML by brute-force through PrintWriter or something. I even escaped strings right since some library I had available conveniently offered the escape method (Guava maybe?).
- SomeCallMeTim 10y ago>well regarded in the enterprise I think this alone should be enough to cast doubt on it, based on my (albeit limited) interactions with "enterprise" software. >I think it's bad reputation comes from anyone not using an enterprise language because the support just isn't there. What, like JavaScript? I've had to read and write XML packets from a Node app to work with (surprise!) an enterprise app. I had probably 20 choices of libraries with varying levels of features, and the one I chose worked fine. I was lucky, compared to some of the others on this page: The "RPC"-style XML commands and responses I had to parse and generate were all well standardized, so I just wrote a wrapper that extracted the completely opaque tree of XML into a flatter JavaScript object/hash that was really easy to deal with, and similarly made a wrapper that would trivially generate the monstrous XML required to send commands and responses back to the server. My JSON-equivalent objects were easier to manipulate (and would also have been easier to deal with in Java or, in this case, C#), equally rich in the information they carried, but could have been serialized with 1/3 the number of bytes per message. Totally a win-win-win. What I don't understand is why anyone thought using XML that way was a good idea, and why it still is popular in the enterprise. Bad habits are hard to break, I guess.
- clockwerx 10y ago> What I don't understand is why anyone thought using XML that way was a good idea, and why it still is popular in the enterprise. Bad habits are hard to break, I guess. Namespaces, which then gives you easy answers for Internationalisation (xml:lang), a subject-predicate-object data structure (RDF), which can lead on to logical meaning/modelling of data (RDFS/OWL), which then lets you look at harder questions like trust/provenance. There's also schema validation (XSD), transformation (XSLT), which then provides you tools like XPath. Most of that is on the front page for the technology: https://www.w3.org/standards/xml/ https://www.w3.org/standards/xml/ The real problem is not syntax, its communication between groups with differing experiences and interests - how do I know your messages mean the same thing as what my system expects? If you prove to be malicious, do I have to write a strict validator before I trust your input? If you want to ensure your messages are well formed before they are sent, do you also have to write a validator? How do I know our validators are checking the same things? If you want to send a large document oriented data structure, but I only care about a specific section relating to my interests; do I have to understand where to look and what all of the surrounding material is; or can I query for the relevant bits? On the more complicated RDF side of things - if you want to share identifiers with me, how do we both avoid calling everything record id=1? If we are both talking about the same thing but know different parts of the story, how can I recognize your information as describing the same thing I know about? If we both know about the same Thing, and know certain logical facts about that Thing, can we check those facts actually make sense against shared rules? If we both know about the same Thing, and can see a logical inconsistency in data, can we reason about which data to Trust and why? Unfortunately, communicating properly is hard even with all of the tools to help. We tend to opt towards subjecting systems to an ongoing fuzzing test because we don't value many of the above things - we tend to work in organisations with a short attention span focused on the now and a narrow set of interests. It just kind of works for the 80% of the time, so we move on. Contrast that with something like a library or museum, and you see why ideas like Dublin Core really catch on there.
- int_handler 10y agoMy impression is that the reason why XML is so well-regarded in the enterprise is because these companies are not aware of better alternatives, such as Protocol Buffers [1]. The reason why XML has a bad reputation outside of the enterprise is because it is so incredibly verbose (both the language itself and the code used for working with it), and that all-in-all, it is a sub-optimal solution to a solved problem. To illustrate: Protocol Buffers' wire format is much more compact. It removes the complexity of having to deal with XML parsers by providing classes generated from the message definition/schema. You can use it with GRPC to implement your service APIs. It is supported for many different languages, including Java and C#. It now even has a JSON mapping [2]. Overall, Protocol Buffers can do everything XML can do as both an exchange format and as a configuration language but better. [1] https://developers.google.com/protocol-buffers/ https://developers.google.com/protocol-buffers/ [2] https://developers.google.com/protocol-buffers/docs/proto3#json https://developers.google.com/protocol-buffers/docs/proto3#j...
- HelloNurse 10y agoProtocol Buffers are just one of many proprietary serialization libraries. Regardless of technical excellence, Protocol Buffers and competing libraries are automatically much less suitable for actual enterprise use than open standard serialization protocols with multiple interoperable implementations, such as ASN.1. And of course, XML is usually preferable to ASN.1 or the like because it is equally standardized but it has an ample choice of implementations, advanced tools and human readability and writability.
- chii 10y agoProtocol buffer isn't proprietary. It's just not a standards based protocol. But it doesn't stop you from writing code against it, and you can easily interop with a third party who is using protocol buffers.
- int_handler 10y agoProtocol Buffers is not proprietary. It is open source under the BSD license. Here is the source code: github.com/google/protobuf. It is very much an open protocol, and anyone is free to write their own implementation of it. It is just a standards-based protocol. If your organization values the existence of a standard over technical excellence, then there is no use in convincing you. Otherwise, in terms of ease of use, performance, tooling, and human readability and writability, Protocol Buffers is superior to XML-based protocols (since the API for converting between the binary and text formats is extremely simple to use). As a fun fact, if you really wanted to use XML as a wire format, you could even write an XmlFormat ser/de for Protocol Buffers, similar to the JsonFormat that is already provided, but then it would defeat one of the main purposes of using Protocol Buffers in the first place because you would replace an extremely performant wire format with an extremely sub-optimal one.
- brightball 10y agoAnother part of it is that statically typed languages benefit much more from XML with a strictly defined schema like DTD or XSD because it makes it easier to generate the objects that you're going to have to map it into. With a language like Ruby, PHP, etc that isn't strongly typed it's not nearly as big of a deal. Developers in those languages are used to assuming everything is a string and converting it to something useful without the need to premap every datatype. That's probably the main reason that XML was so much more popular with the languages you mention compared to the parts of the ecosystem that didn't benefit from it's constructs much (if at all).