Thanks for your response Jay, and thanks also to Jeff for hitting one of my followup questions. ;-) I assume the primary difference between cmis:versionSeriesId and this hypothetical new identifier is that the new identifier would be mandatory for all objects (unlike cmis:versionSeriesId)?
I wonder if there's some way to make cmis:versionSeriesId mandatory in a future version of the specification instead of creating a new type of identifier, so as not to overload consumers with three different forms of identifier? Really only two forms of identifier should be needed, as best I can tell:
Identifier of the latest version of an object (whatever that is)
Identifier of a specific version of an object
It would also be beneficial to "overload" all of the services that currently take a cmis:objectId with the ability to take a cmis:versionSeriesId (or the new identifier, if a 3rd type of identifier is the chosen path forward) instead. Right now the only services that are like this are getObject / getObjectOfLatestVersion and getProperties / getPropertiesOfLatestVersion, but arguably every single service that currently takes a cmis:objectid should accept either type of identifier.
Finally, I also wanted to mention that getObjectByPath is unsuitable for this purpose, as paths aren't immutable (which makes them poor identifiers).
Cheers,
Peter
On Oct 8, 2013, at 1:00 PM, Jeff Potts <> wrote:
How is what you are proposing different than the cmis:versionSeriesId?
Jeff
On Oct 8, 2013, at 12:00 AM, Jay Brown <> wrote:
Peter,
Seems like a reasonable question to me.
I would guess this came as an attempt to model CMIS in a way that was capable of dealing with repositories that had the concept of a version series object where each version therein was independently persistable and securable. (FileNet is an example of this) E.g. User A might be able to read/write versions 2 and 3 but not any of the other versions.
Note: We are discussing (just came up again today in the TC meeting) the concept of a type of dynamic ID that would always refer to the latest version in the series much the same way that a path can today.
Jay Brown
Senior Engineer, ECM Development
IBM Software Group
<graycol.gif>Peter Monks ---10/04/2013 01:34:13 PM---G'day TC, Quick question (though I suspect the answer may not be ;)…
<ecblank.gif>
From:
<ecblank.gif>
Peter Monks <>
<ecblank.gif>
To:
<ecblank.gif>
<ecblank.gif>
Date:
<ecblank.gif>
10/04/2013 01:34 PM
<ecblank.gif>
Subject:
<ecblank.gif>
[cmis] Question on cmis:objectid
<ecblank.gif>
Sent by:
<ecblank.gif>
<>
G'day TC,
Quick question (though I suspect the answer may not be ;)…
Why are cmis:objectid's version specific? By that I mean, why do they refer precisely to a specific version of a versionable document, rather than a document in its entirety?
The background for my question is that this trips up most of the client implementers I work with (3 in the last month alone!) and when asked to provide an explanation of why this is better than alternatives (e.g. having cmis:objectid's refer to the object in its totality, with versions of that object accessible via some complimentary mechanism) I'm at a loss.
Thanks in advance,
Peter
---------------------------------------------------------------------
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
Jeff Potts | Chief Community Officer
m +1 214 405 4957 | skype/twitter jeffpotts01 | blog ecmarchitect.com
I'll see you at the Alfresco Summit | Barcelona, Nov 4-7 | Boston, Nov 12-15 | http://summit.alfresco.com
Alfresco - Do Great Work
twitter.com/alfresco | facebook.com/alfrescosoftware | youtube.com/alfresco101
