Re: [cmis] Investigating CHECKIN verb for CMIS

[Julian Reschke <julian.reschke@greenbytes.de>]

Al Brown wrote:
> Julian,
> 
> I thought I would also start a thread investigating CHECKIN verb as 
> well. Upon reading, http://tools.ietf.org/html/rfc3253#page-38 here are 
> some conflicts with the current RFC:
> 
> #1 Request Body must be DAV:checkin. CMIS would want it to be the atom 
> entry for properties update if provided.

So you want setting properties + checking in done in one atomic 
operation? That could be solved by extending DAV:checkin to carry an 
additional container element holding the properties (that's a typical 
case of using the DAV extensibility model).

> This can be done if CMIS REST/APP does not want to support 
> checking(objectId, properties, content stream) but rather 
> checkin(objectId) - e.g., not information on checkin just the action.
> 
> #2 The pre & post conditions are DAV specific and would not apply. In 
> general some of them would:
> a - reflected in version history

Can you elaborate? A checkinop that is *not* reflected in the version 
history?

> b - uri provided for checkedin version. CMIS provides an URI on both 
> checkout and checkin. The URI could be new on checkout and then constant 
> or new on checkin, or new on both checkout and checkin.

You're probably looking at simple versioning (checkout-in-place 
feature), where CHECKOUT just flips a bit, and CHECKIN creates a new 
version resource.

The CHECKOUT type you are looking for (CHECKOUT creates a new resource) 
is defined in the "workspace" and "working resource" sections 
(<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.6> and 
<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.9>).

> #3 - checkin comment is not supported by CHECKIN.
> 
> This would have to be modelled.

In WebDAV, this is just a string property with a well-known name; 
shouldn't be a problem in CMIS.

> So, provided we wanted to write an RFC, we could get CHECKIN to work 
> with CMIS, but I think it is in the same camp as MOVE/COPY.

I agree that making CMIS + RFC 3253 co-exist is likely to be harder than 
  using WebDAV namespace methods.

> UNCHECKOUT:
> 
> CMIS currently models this of the deletion of the private working copy 
> resource. I overlooked mentioning in CMIS that documents are version 
> specific. This modeling of DELETE of pwc seems sufficient and intuitive.

I think it's the same for RFC 3253 "working copy" resources.

> So I don't see the need to change that mapping since the PWC is modeled 
> as a separate resource.
> 
> Thoughts?

It's great that you're looking at this. Even if we do not use RFC 3253 
verbs in the end for other reasons, it's good to compare the versioning 
models of CMIS and WebDAV. It seems to me that CMIS versioning is 
similar to the RFC 3253 "working resource" feature...

BR, Julian

-- 
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782