OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]



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* 

"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 

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]