It seems the SEC has agreed on using the version uid value as the composition uid value. This was commented in the SEC slack but doesn't seem to be documented anywhere. Also is not clear if this is a hard requirement or a recommendation, and if the latter, what are the implications of not using the version uid as the composition uid value.
You missed the second part of my sentence: our implementation actually takes the whole OBJECT_VERSION_ID from version and puts is into Composition.uid. When our server generates composition UIDs, they are OBJECT_VERSION_IDs with three parts separated by double colon, and identical to their versions' uids. Do other implementations differ? If not, that should be what the standard proposes, if it does, we need to talk.
We have the same (since our beginning in 2010) as Matija is explaining; I remember this was also the way Ocean had it at that time. I would say this is necessary especially when Compositions are managed through an api (by an external application) and not by same system
Ok, I had not realisd this. Matija, can you please create an email on the SEC mailing list describing this and asking what is in all the implementations. Sorry for it being a bit of a time-waster, but this is important and we need to know what the systems are really doing. I will of course document it whichever we it really is, but we need to know first what all the current implems actually do on this point. If you can chase this and obtain some answers, I will use the results accordingly to fix the documentation.
I can confirm that we have the 3 part id in Composition.uid and all other vendors seem to have followed the practice. I remember raising this a while back, glad to see it agreed.
resolved in RM Release 1.0.4