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]


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 Brown
ECM CTO Staff, Information Managament
Office 714 327 3453
Mobile 714 263 6441
Email albertcbrown@us.ibm.com
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.

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


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




"'Julian Reschke'" <julian.reschke@greenbytes.de>


01/15/2009 12:02 PM




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),

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

- 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 [
Sent: Thursday, January 15, 2009 06:29
To: cmis@lists.oasis-open.org


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

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

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:

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:

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