Thanks Florian - I appreciate the explanation. This doesn’t really have any bearing on the fact that this has a significant practical impact on client applications however. I would hope that the TC is open to reconsidering historical decisions such as this in light of practical feedback from industry, even as they strive for theoretical purity in the spec.
Cheers, Peter On 2014-06-19, at 2:48 AM, Florian Müller <f...@apache.org> wrote: > Hi Peter, > > This has been discussed a long, long time ago, before CMIS 1.0 has been > released and the result is documented in section 3.1.9. > > The problem is that the AtomPub spec does not define a response payload > to media edit PUT requests. That is, we cannot return the object ID in > the payload AND being AtomPub compliant. > Early CMIS drafts transported the object ID in a non-standard HTTP > header. This has been heavily criticized by HTTP experts and the CMIS TC > decided not go that route. > > As long as nobody has a great idea how to return the object ID without > violating the AtomPub or the HTTP spec this is not going to change. > > > - Florian > > >> 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" >>>> >>>> >> >
