[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: On "HOW DOES CMIS RELATE TO OTHER STANDARDS EFFORTS?"
Hi, I just re-read this part of Part 1 and I really think it needs either to be rewritten or dropped. Let me explain why. The prose emphasizes the fact that CMIS consists both of an abstract model and services, and API/protocol bindings. There's nothing wrong with that, and it's a good thing to have, but it's totally not that different from either JCR or WebDAV. Both of these, although defining a Java API and an HTTP extension, of course *also* define an underlying model (for instance in RFC 4918, Sections 4 to 7). So for this whole section to be useful, it would need to look at the specific models, and compare them to CMIS Part 1, "Data Model". In particular: "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." I have implemented JCR on top of two existing document management systems, and in my experience, JCR does not require any specific implementation at all. At all. On the contrary, it's quite simple to expose various kinds of subsets of the "full" JCR feature set in a JCR-compliant way. If there is a problem, then it's that JCR leaves *too much* flexibility to the implementations, in that it may be tough to write interoperable clients. Looking at CMIS, I see lots of things that appear strange to me -- probably because my work experience is not with the ECM systems of Filenet, IBM or EMC. For instance, it's not clear to me why relationship objects are a special object type, nor why they can't be filed, or why they can be returned in response to getChildren if they link to one of the collection members. There's surely a good reason for that, but as far as I can tell, CMIS only differs from previous models in that it imposes a *different* design. In particular, as it currently requires XML Schema support (we may want to get rid of that) *and* SQL support -- now that may not appropriate for many types of applications, or efficiently layered on existing repositories (quoting CMIS itself, but substituting "ECM repositories" by "repositories"). That having said, the information about WebDAV is almost *completely* incorrect: "HTTP Extensions for Distributed Authoring -- WebDAV Reference: http://www.ietf.org/rfc/rfc2518.txt" WebDAV is defined in RFC 4918, published in June 2007. "However, the DAV standard is lacking in a few key areas that are critical for the use cases listed above, including: . The ability for a repository to expose a heterogeneous set of Object Types within a single repository or folder." I have no idea what this means. Whether a WebDAV collection can contain only specific types of resources (such as in CalDAV) or not is totally open. ". The ability for a user to issue a “query” to retrieve & interact with a collection of objects, regardless of their logical storage location." RFC 5323. ". Relationships between objects other than their logical storage hierarchy." Relationships can be defined by setting hyperlink typed properties, as demonstrated in RFC 3253 (DeltaV). "Furthermore, the WebDAV standard also includes several features that are not commonly implemented in modern/mainstream ECM repositories, such as shared and exclusive locking of an object (section 6.1)" Locking is totally optional in WebDAV, so why is that a problem? Multi-filing and version-specific filing aren't commonly implemented either, that's why they are optional, right? "Finally, the WebDAV standard is very tightly integrated to the HTTP protocol – meaning that mapping it onto dissimilar protocols in the future would be a significant challenge. As a result, the authors of the CMIS specification decided that rather than design CMIS as an extension to the WebDAV protocol, CMIS would instead be created as a new protocol that could then be bound to multiple protocols, and that wouldn’t need to worry about backwards compatibility with the WebDAV protocol" Again, that's misleading. The model used in CMIS actually isn't that different from what WebDAV uses. AtomPub is as tightly integrated in HTTP as WebDAV, and CMIS-over-AtomPub needs to worry about compatibility the same way as a hypothetical CMIS-over-WebDAV protocol binding. Best regards, Julian -- <green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht Münster: HRB5782
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]