Comments on: What’s the future of XML?

By: Paulteee

Paulteee — Thu, 16 Jun 2011 23:22:51 +0000

We’ve just had this debate about SOAP web services using XML vs RESTful services using JSON. This is just history repeating itself. Whenever it gets too complex or onerous the developers throw the baby out with the bathwater and “invent” something “lightweight”. It’s only lightweight because they left all the bits out that got added because they were needed like security and interface definitions. Take a look at Spring now. How lightweight is that after they put all the stuff in there that was in J2EE? There is no way I am going to open up my applications to accept JSON without quarantining the payload and examining it first for malicious Javascript embedded within the JSON. At least with XML I can have the schema validate the payload first and apply security policies to the service interface. What would some malcontent ‘script kiddy’ try and attack first? A hardened web service with a policy that specifies a complicated set of SAML assertions or some cobbled up REST service that he/she can fire a bunch of requests at with JSON payloads designed to exploit buffer overflows.

By: HendryB

HendryB — Tue, 03 Nov 2009 17:45:06 +0000

I have also been in IT for over 20 years and worked with EDI, XML, raw data, IIOP, etc. JSON does not ease implementation. In fact, it is more complex to read the output than XML. The statement that XML is data is correct. But the idea that XML based systems will be replaced by IIOP pr even JSON seems a bit odd to me.

XML is text therefore compressible without degredation or loss of information. It is still human readable (both a strong and weak point) throughout the transmission process. And, ultimately, it is (as the name implies) eXstensible. Yes, for web front ends, JSON is a good fit. However, in practice, that does not negate the use of XML. It is easy enough to transform XML to JSON with a simple method call that adds no more overhead to a server than an XML Transformation using XSLT.

I would caution everyone not to get distracted by bright shiny objects. There are so many security risks that are introduced by new technologies. XML has been around long enough that many of the security issues have been addressed. And, in a SOA, the WSSE and XML Encryption add the levels of security necessary for robust, survivable, scalable, and sustainable architectures necessary to deter weekend hackers and script kiddies.

True, implementation of those components in the WSSE is painful and can cause network traffic to increase (as you gather things like x509 certs from a PKI). But in the end, the goal is to have something that is easily understood by your developer, network architect, and network security groups.

By: PlexPro

PlexPro — Fri, 02 Oct 2009 15:32:36 +0000

JSON is for process, XML is for data…

By: Aaaqqq1234

Aaaqqq1234 — Mon, 28 Sep 2009 17:19:40 +0000

The problem with those dumbed down communication protocols is that they don’t keep any types, ANY types, not even real, integer, or anything except string.

So when you talk about “JSON was kept simple– simple values (numbers, strings, Booleans), simple sequences of values (arrays, vectors, lists) and a simple collection of named values (object, record, struct, hash, proprietary list). ” it sounds misleading because JSON is a simple dictionary list of key-value pairs and strings on top of that.

Now plz tell me how to send an order object or an invoice object over JSON without getting into a mess.

By: ConstructionIT

ConstructionIT — Thu, 24 Sep 2009 15:55:10 +0000

Tring to get standards across the IT spectrum has and will remain challenging. In the construction industry there has been a push to embrace XML and demand it in all construction software for the transactional data that is now commonly exchanged in paper documents. New, faster, easier and innovative solutions are always there…we call them disruptive because they upset the efforts put forth by our own IT experts. XML will stay for the short term but I suspect it will not be permanent.

By: Dyna

Dyna — Tue, 22 Sep 2009 17:20:32 +0000

[B]XML is a development-language not a runtime language [/B]
XML has got a lot of tool-support and a whole lotta money has been invested in this technology, so it won’t disappear very soon. But I think the fundamental mistake that has been made is that we started considering XML a runtime language for intersystems-communication instead of a development-time language. While it makes sense to define messages and transformations using XML-related technologies, it doesn’t make sense to use XML for the actual communication that takes place. Better technologies like JSON or IIOP have been developed for that purpose.

By: CDPauley

CDPauley — Tue, 22 Sep 2009 14:09:49 +0000

When I got into the IT world 20+ years ago, EDI was the way businesses communicated with each other. When I started reading about XML in the mid to late 1990′s, the prophets predicted the demise of EDI because XML would replace it. EDI is still here and in use though not near as much as it was 10 years ago. XML just couldn’t completely replace EDI. The role of XML will in no doubt eventually subside but I seriously doubt it ever going completely away.
Over the years I have seen a lot of new ideas that would “transform” development and how we use computers. In retrospect what I have seen is new trends, some stuck and some fell by the way side. Where the new is cost effective and makes since then use it. Where it doesn’t, well stick with what works.

By: Greg1martin

Greg1martin — Tue, 22 Sep 2009 13:31:33 +0000

The simple always moves to complex until a renovation attempts to remove the complexity The old is always replaced by new. Often, the new is just something old with a few wrinkles removed.