Thanks Florian - that confirms my analysis. I’ve raised a bug report<https://issues.oasis-open.org/browse/CMIS-774> [1] against the specification for this.
Cheers, Peter [1] https://issues.oasis-open.org/browse/CMIS-774 On 2014-06-18, at 3:14 PM, Florian Müller <f...@apache.org<mailto:f...@apache.org>> wrote: Hi Peter, There is no standardized way and therefore OpenCMIS doesn't do it. However, it is not impossible. The server must send a Location header in the response of a setContentStream request. The value of this header is a URL, which contains the new object ID. The problem is that the pattern of this URL is not standardized. If you know the server implementation and the URL pattern, you can extract the object ID. If you don't know the pattern the best you can do is guessing. But that is not implemented in OpenCMIS and hidden from the application. We could implement some heuristics here, but that would never be 100% reliable for all servers. - Florian G’day, I realise this is a general CMIS question, but the TC doesn’t provide a general purpose Q&A / discussion mailing list, and this seems to be the nearest thing. Section 3.1.9 of the CMIS 1.1 specification states that the AtomPub version of the setContentStream service doesn't return the cmis:objectId of the new version of the document (note: this is an exception to the domain model, section 2.2.4.18.2). The Apache Chemistry library that I’m using (Java / OpenCMIS) faithfully implements this behaviour. My question is - how can a CMIS client application efficiently* obtain the new cmis:objectId value, after setting a new content stream on a versioned cmis:document via AtomPub? Thanks in advance, Peter * where "efficiently" means "without further round trips to the CMIS server"
