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]

Subject: Re: [cmis] Question on cmis:objectid

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:
  1. Identifier of the latest version of an object (whatever that is)
  2. 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).



On Oct 8, 2013, at 1:00 PM, Jeff Potts <jeff.potts@alfresco.com> wrote:

How is what you are proposing different than the cmis:versionSeriesId?


On Oct 8, 2013, at 12:00 AM, Jay Brown <jay.brown@us.ibm.com> wrote:

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 ;)…

Peter Monks <pmonks@alfresco.com>
10/04/2013 01:34 PM
[cmis] Question on cmis:objectid
    Sent by:

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,

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:

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

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