|Subject:||Re: [cmis] Investigating CHECKIN verb for CMIS|
|From:||Al Brown (albe...@us.ibm.com)|
|Date:||Apr 16, 2009 11:28:05 am|
Cmis allows the repository to choose when the version history is updated: 1. At checkout (ibm has a rep that does this) 2. At checkin (enc has a rep that does this))
Ibm's rep that does this changes the state and security on checkin but does not update the version history.
CMIS requires the version history to have the version after checkin but does not require the addition of the version to history on checkin as it may have happened before.
------Original Message------ From: Julian F. Reschke To: Albert Brown Cc: Julian F. Reschke Cc: cmis Subject: Re: [cmis] Investigating CHECKIN verb for CMIS Sent: Apr 16, 2009 10:11 AM
Al Brown wrote:
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 ha
------Original Message Truncated------ Sent from BlackBerry.
--------------------------------------------------------------------- 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