It started with an idea I had, in an innocent sort of way. I thought if I looked at the JCR specs for a bit I might find some kind of way of building a non Java interface with them. You know, maybe there might be a nice REST architecture waiting to get out. But of course there is no such thing. It is an application definition. There are not even that many ways of implementing it, other than choosing your object persistence method to be a database, file, or something else.

The REST architecture is notionally provided by another layer, such as Apache Sling, but Sling is in no way a REST layer, it is a URL dispatcher and scripting and application layer with which some REST style applications can be developed. With that you end up with a pretty heavyweight development framework, indeed together you have much of Day’s CMS offering in effect, rather than a lightweight REST repository solution.

I had a look at CMIS again. Fielding once laid into CMIS for not being REST and you can see why, although some improvements have been made since that. Although resources are discoverable through hypertext, there is a fair amount of semantics that needs to be known to understand what a type or a checkout means, and the search queries are obviously just RPC wrappers. It is not too bad though, but unfortunately the data model does not map well onto web content management right now for obvious historical document management reasons. Fixable? I think it serves a part‎icular purpose well and should probably not be forced into anything else, as we need it to succeed in its field.

Day claims that JCR is not a Java standard in an odd way, that you can implement the API in another language. Thats a strange argument to make, especially as the types are defined as Java types, and standards without interoperability are pretty vague. Without some sort of wire format or ABI this is meaningless outside the JVM world. People are making JCR like repositories in PHP but outside any standards process, so in the end this just becomes a PHP repository project; Typo3 seems to be building another, also closely aligned to JCR.

The problem with these efforts is that it is not helping the balkanization of web CMS, which is already fragmented by language and API, which is ridiculous in an industry that is about the web. The web has an architecture (REST) and an API (HTTP). Building web content management on Java APIs or PHP APIs or .NET is a legacy way of thinking; it is acceptable for document management given its role in existing enterprise architectures, but it is not going to work if we want to get widespread acceptance in web development; in the short term it is the easy path, it is what people are used to, but a forward thinking industry needs to look at defragmenting the landscape and building future proof tools.

The odd thing is that a web content repository alone surely lends itself to a simple REST architecture. Content is after all lots of small resources with relations. Hypertext. It is pretty much in presentation a fairly dumb web application, although with a fair amount going on behind the scenes. It takes content, relates it to other content, and serves it back, with authentication and versioning. Everything else is in other system layers, transforming it and so on. Not simple, but well defined; lower level than JCR + Sling say

So we need to work on a web content repository model, as a community. Process wise, it makes sense for this to sit in an organization like AIIM, as a content management based industry body. It may well be that what ends up coming out of this is more standardized architectures and semantics and open source implementations rather than the tighter prescriptions of JCR and CMIS; I have some ideas along these lines that I need to code up. I have had some discussions and there is a degree of interest in some sort of solution; who is interested? Or is infrastructure dead, everything ust wants interfaces?

In content management the old saying has not really been relevant. There have not really been many standards. Then one day JSR-170 turned up, a Java content management standard.

Then CMIS.

Then the other day, JSR-283, ostensibly the simple successor to JSR-170 suddenly split into two, one part the data model and the other part the Java API. Clearly leaving room for a non Java API track. Not being on the standards group I do not know when this happened, but it does smell like a bit of reaction to CMIS. And indeed Roy Fielding from Day did react to CMIS recently in a not happy way.

Previously most of us outside the Java CMS world looked on the Java standard as being a pure Java move. Many standards attempts now are about strategic commercial interests. Actually though within the Java world it seemed to be quite well accepted, and Magnolia and Day could live in the same world. Deeper down though, is it an attempt to define ranges of functionality within product ranges? Although the specification does not correspond to the implementation necessarily, both constrain each other, especially in some parts of these specifications.

CMIS was a different matter. A different set of vendors, a similar model, a different set of APIs (a non RESTful REST that Fielding could lay into!). But the biggest criticism of JSR-170 was simply the J; anything could look credible by being more inclusive. Hence I think the current changes in JSR-283.

The CMIS draft states

The JSR standard requires a particular type of implementation for ECM repositories: Whereas CMIS restricts itself to specifying only generic/universal concepts for ECM constructs like Documents and Object Types that could be layered on most existing ECM implementation, the JSR standard requires a highly-specific & feature-completion implementation of a repository. This structure may not be appropriate for many types of applications, or efficiently layered on existing ECM repositories.

This is core to Fielding’s substantive criticism – it is just trying to model folders and files, and a WEBDAV interface does that fine. JSR defines abstract item and property trees, that the CMIS players feel don’t fit with their content models. The CMIS draft mentions webdav, but says it misses out on types and queries, locking, and not http interfaces(!).

Jon Marks http://jonontech.com/2009/04/09/cmis-is-xpath-just-a-bit-too-tricksy/ points to the XPATH/SQL distinction. XPATH too is a bit modern for the CMIS vendors. The XPATH expressions refer to the XML representation of the property tree, which if it does not actually correspond at all to your internal models or implementation method is quite a lot of work to implement.

There is some truth in the implementation specific parts of the criticism of JSR, in that I am not aware of any implementation of the JSR standards that does not use a JSR native content repository as the base implementation (eg Jackrabbit). Maybe I have missed one. Partially that is because it is a strong model for a moderns CMS, with excellent open and closed source implementations. Partly also that not many vendors have yet explored related but dissimilar frameworks (it is not clear that an RDF model would fit well for example as properties are first class; though a mapping may be possible the semantics of an object may end up differing). The other area in which differences will probably become apparent are the versioning models, though these will not necessarily be exposed through interfaces if there is a big mismatch.

In an abstract sense the differences in the two models seem small. In CMIS documents have a (single) body and then additional properties. In JSR objects simply have properties, the “content” is simply anther property. Although that sounds subtle and easy to switch models – just add a type property and a content property to documents, not to folders, there are more and more model differences the further you go. Locking for example. And the rules about folders not being versioned while files are, and the primacy of the document folder containment relationship. Another difference in CMIS is the large list of optional facilities, such as the query types available, and whether checked out copies or versioned copies of documents are accessible through the query mechanisms.

Overall there is a difference in what the “generic/universal concepts for ECM constructs” are. Two formalized models is actually a useful start to help classify the CMS models that exist. A web services interface to JSR will help that model expand outside the Java only area. Islands of interoperation or at least data transfer can only help the industry as a whole.