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

This is a good point.  As we look to get the first internal draft together after the F2F, in addition to the OASIS templates this issue should be addressed as well.

-Al

Al Brown

ECM CTO Staff, Information Managament

Office     714 327 3453

Mobile   714 263 6441

Email     

CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. 

"Dennis E. Hamilton" ---01/15/2009 12:02:07 PM---Julian,

From:

"Dennis E. Hamilton" <>

To:

<>

Cc:

"'Julian Reschke'" <>

Date:

01/15/2009 12:02 PM

Subject:

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

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:] 

Sent: Thursday, January 15, 2009 06:29

To: 

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 

---------------------------------------------------------------------

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