9 responses to “Data Standards for Web Applications”

  1. Krishnan Subramanian

    Espen, check out Microformats. There is some progress in this area but we need to do more. One thing is clear. The only way for Cloud Computing to succeed is by having open formats. Proprietary formats can only go to a certain extent when it comes to data portability and interoperability.

    Plus, I disagree with the idea that open source becomes irrelevant in the Cloud based world. Even people like Tim O’ Reilly seem to promote this line of reasoning. But as we have seen with WordPress, Deski Wiki and Wikidot, releasing the source code is no hindrance to a business and if companies like Coghead are any indication, it is important to share the source code to ensure that consumers trust cloud based applications. I have written on this topic a few time here at Cloud Avenue. I also have a plan to do a dedicated post on this topic but I keep on postponing it.

  2. Espen Antonsen

    Krishnan; Naturally Stallman as well disagreed with open source being less relevant. But Lie’s point was not really about that, though he did argue that the data is more important than the source code, but about the importance of standard data formats.

    I am aware of microformats but did not think of it when I wrote the post. Thanks for reminding me. They do seem to include lots of overhead though.

  3. Henrik Lied

    I can’t really see the need to normalize data to conform to certain made up standards. For some data, sure (you used accounting as an example), but for most services, a little parsing isn’t really that hard.

    With the introduction of lightweight data interchange formats like JSON, it’ll only take a couple of minutes (or hours at the most) to create a stable parser for most APIs. Let’s not get too lazy and comfortable! 🙂

    I really wish XML would die. JSON is a much more compact and usable interchange format which has great support in most languages by now. It’s also much more web-friendly, as it’s plug and playable into JavaScript.

  4. Espen Antonsen

    @Henrik True, many formats are fairly simple and not at all hard to parse – for you or me. But that is not the case for the average user. And the data I mainly refer to in my post is mainly business data which tend to be more complex, thus the need for standard data formats to ensure data portability.

  5. Martin Kleppmann

    Espen, thanks for a great post. I fully agree with your view that accounting needs an open standard. I am actually in the process of writing one at the moment: OAccounts aims to provide interoperability and data synchronisation between accounting systems. It’s still early stage, but I’ve blogged about OAccounts and would welcome input from anybody with an interest in this area while I write a draft specification over the next few weeks.

    @Henrik One really valuable thing which an open standard offers you is the ability to plug a large number of different implementations together without ANY integration or parsing work at all. If you have N different systems, each with a different API format, then connecting them all requires in the order of N-squared parsers to be written. That soon gets ridiculous. With an open standard, you only need N implementations of that standard.

    Think of email as an example for a very successful open standard. Now imagine that GMail decided to implement its own, incompatible set of mail headers so that everyone who wanted to exchange messages with a GMail user had to implement Google’s protocol. Yes, it would be possible, but a right pain in the backside; it is because everybody has bothered to implement (more or less) the same SMTP and MIME standards that we can simply send an email and expect it to work.

    Finally, regarding your note about wanting XML to die. I would agree to this regarding things like configuration files, which are supposed to be human-readable; having these in XML is horrible. Similarly, if everybody is going to make up their own XML schema, then it’s also fairly pointless and you might as well use JSON. XML becomes really valuable then when a bunch of bright people have sat down for a long time and carefully designed a well-thought-out schema for a particular purpose. For instance, I am planning to use the OASIS UBL 2.0 XML schema for OAccounts. It works really well because these guys have thought about issues of multi-currency, international transactions, international taxation, shipping of goods by container, various banking and multi-party purchaser-supplier relationships which you get in the real world. If I was to make up a schema myself — be it XML or JSON, it doesn’t matter — I would never think of all those things, and we would hit limitations as soon as we tried to put the thing to real-life use. By using this existing schema, I feel confident that we can scale to complicated use cases, but at the same time not introduce too much extra complexity in the simple use cases.