When the Java Content Repository (JCR) standard first came out it was supposed to bring in a new era of compatibility between content repositories and put an end to the content silo. There was, and still is, a lot of talk about it and just about everyone added JCR compliance to their marketing materials. Unfortunately, that’s mostly where things stopped – the implementation work that followed was generally done was buggy or incomplete and the only viable JCR implementations that I’ve seen have come out of Day Software, who lead the JCR spec effort. There are a few CMSs around that do have good JCR support – Alfresco for example – but they’re few and far between and even with that, there isn’t a lot of people taking advantage of that support and the standardization of the repository interface.

Then along came Atom which is all about remote access and manipulation of data and missing probably 90% of the functionality that JCR offers. It really isn’t a competitor to JCR at all and yet it’s doing more to break down content silos than JCR ever has. Atom support isn’t just being added to the marketing materials, it’s actually shipping and is usable in a lot of places – IBM’s Lotus Connections has Atom APIs to everything and, as best I can tell, only Atom APIs to it’s repository.

Atom seems to have walked the line between simplicity and power just right, and even in the cases where it’s too simplistic it’s extensibility is so effective that you hardly notice. Connections for instance makes heavy use of the pagination extensions to make sure that content doesn’t drop off the bottom of the Atom feed and out of existence. Having Atom support in your product, serving and consuming as necessary is becoming an extremely powerful feature.