One on One with David Nuscheler of Day Software

There has been a lot of coverage in this space (and elsewhere) about CMIS [1] including an Editor's Corner [2] when it was announced, and a subsequent interview with Alfresco CTO and chairman John Newton [3]. This week, I interviewed David Nüscheler, CTO at Day Software [4]. He knows a thing or two about standards as the Spec-Lead of JSR-170 and JSR-283 and a member of the Apache Software Foundation. I asked Nüscheler to give me his views on CMIS and where it fits in the content management standard landscape. Nuescheler thinks some companies may be putting the cart before the horse when it comes to announcing products for an unapproved standard:

FCM: What's your view of CMIS?

DN: I think there are different ways of looking at CMIS. I am definitely excited about the fact that a group of CMS vendors get together and work on a specification. The CMS market is missing a widely supported protocol specification that would address the communication between applications and a content repository. This is essentially what JCR does for the Java world.

CMIS represents a complementary standard to add interoperability between Java- and non-Java based content repositories. Having said that, CMIS is very focused on the requirements of document management--ignoring critical requirements around web content, digital assets and more--and of course there are a number of substantial technical issues with the specification at this stage, some of which has been the subject of much recent discussion on blogs and in the press. Of course, at this stage of any specification, such community discussion is to be expected--and welcome--to help drive a solid spec. As with my efforts with JCR, I am looking forward to working with the other proposers to address these issues representing Day and JCR on the OASIS technical committee.

Day believes strongly in the future of standardization of content repositories, and for this reason Day led an industry-wide effort to specify and ratify the CMS industry’s first content repository standard, JSR-170, and continues to drive efforts around standardized Java Content Repositories with JSR-170’s successor, JSR-283.

FCM: Why weren't you on board with the other major CMS vendors in helping define the preliminary CMIS specification?

DN: In the official submission to OASIS [5] we are listed as one of the proposers of the specification clearly with the intent to make sure that the underlying technologies are used in a compatible fashion. We think that this is not the time to blow the marketing horn on something that eventually will evolve into an OASIS specification. I think any early implementation touted by some prior to a finalization of the spec is getting a bit ahead of where the spec is. As a matter of fact in other standards bodies it is not allowed to announce compliance of products before the final release of a standard because it really is nonsense to do that.

FCM: Will Day participate in defining the CMIS standard now that it has been submitted to OASIS?

DN: We are a proposer of CMIS and will participate actively in the technical committee.

FCM: During my interview with IBM, Microsoft and EMC announcing CMIS, one of them intimated that CMIS was simpler than the JSR 170 standard you helped define. Do you agree?

DN: CMIS has a much more limited domain model. It essentially considers everything a document or a folder. This limitation makes it definitely more intuitive for DMS vendors to implement, but because of that focus it is irrelevant (by design) for all the other use cases like WCM, DAM, Social Collaboration or even Configuration Management hence those amongst other are explicitly excluded from the specification.

FCM: What are the differences between the CMIS and JR-170 in terms of what they are trying to achieve?

DN: CMIS is a protocol specification, JCR is a Java specification. Much like for example, the HTTP and the Servlet specification they are complementary. CMIS is really a DM interoperability specification and therefore has a much more limited scope. I think the biggest difference in scope though is that JCR, beyond its interoperability goals, also defines a standard that for content repository infrastructure. This allows application developers to build their applications based on true infrastructure by giving them the flexibility in their domain model but it also allows organizations to consolidate content repository infrastructure.

FCM: Do you see yourself as an outsider at this point for criticizing CMIS?

DN: I feel like CMIS is definitely overhyped for what it is at this point, so I see our position as neutral and fair for a specification at this point. Some vendors choose to use a lot of marketing noise, which is definitely not appropriate at this point in time.

Having lived through specifying standards I can only say that the glamorous announcements in the early days of a specification process usually don’t pay out and turn into apologies. The standards that really make a difference today (HTTP, URI, TCP/IP...) have never come with big loud announcements when they were about to be submitted to a standards body in their 0.x versions.

FCM: If OASIS ultimately approves CMIS as a standard, will you be on board?

DN: We are on board with CMIS to begin with. This is the wrong time to pledge product support, since at this point we don’t even know at what the final specification will look like and what the certification process for a product will be. That’s precisely why standards bodies normally have anti-FUD policies.

Related Articles:
One on One with Content Management's Movers and Shakers [6]