| 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
How is what you are proposing different than the cmis:versionSeriesId?
Jeff 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
jay.brown@us.ibm.com
<graycol.gif>Peter Monks ---10/04/2013 01:34:13 PM---G'day TC, Quick question (though I suspect the answer may not be ;)…
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
|