RE: [cmis] On "HOW DOES CMIS RELATE TO OTHER STANDARDS EFFORTS?"

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Julian,

Thanks for this.  It reminds me that there are numerous passages in the
current materials that do not belong in the OASIS Standard.  Rationale
doesn't go in the body of a standard (and is apparently best provided in a
separate expository document), and certainly mentions of products,
assessments of other specifications (apart from normative reliance on them),
etc.

This shows up in the 0.5 materials and, for example, in the recent document
on access-control lists.

It is a little broad as a single issue, but this should probably be added to
the issue list to remind us to figure out how to excise that material and,
as desired, place it in some expository text that we might provide separate
from the specification (and not referenced from its references or normative
material).

 - Dennis 

PS: The material was certainly relevant to chartering questions and probably
in developing understanding among those who would elect to support the CMIS
effort, but it doesn't belong in the specification itself.

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@greenbytes.de] 
Sent: Thursday, January 15, 2009 06:29
To: cmis@lists.oasis-open.org
Subject: [cmis] 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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php