The choice of having 3 different concepts (cmis:name, cmis:contentStreamFileName and relative path segment) was deliberate and allows various vendors to expose their internal models without ambiguity.
If cmis:name is used for path composition then the client is simply broken. Path composition must only be done using relative path segments. I know that Adobe Drive 2 is already broken in this respect, but please let's not dumb down the spec for the benefit of bad implementors (who in this case had advance warning during their beta phase that their implementation was broken...). Florent On Tue, May 10, 2011 at 8:52 PM, Jens Hübel <[email protected]> wrote: > > This looks like needing a fix in the errata. If it is not specified. > > I wonder how much sense this property makes at all if cmis:name is uses for > path composition and the unique name constraint within a folder? Does anyone > use contentFileName for this? > > ------------- > This message is sent from a mobile device. > > > ----- Original Message ----- > From: Florent Guillaume <[email protected]> > To: [email protected] <[email protected]> > Sent: Tue May 10 18:55:31 2011 > Subject: Re: svn commit: r1098638 - > /chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/types/DocumentTypeCreationHelper.java > > On Tue, May 10, 2011 at 6:15 PM, Florian Müller > <[email protected]> wrote: >> The spec allows cmis:contentStreamFileName to be read-write but I think it >> would be inconsistent. It's probably an oversight since the Updatability is >> set for all properties except for this one. It doesn't not even say it is >> repository specific - it's just missing. > > I can see a clear use case for wanting to change the filename of an > existing document without rewriting the whole content stream. In this > case having cmis:contentStreamFileName writable is a clear win. It's > much less common to want to change the mime type after the fact. > >> The file name and the MIME type are set together with the content in the >> contentStream structure when a document is created or content is updated. >> If a client sets the file name in contentStream and sets >> cmis:contentStreamFileName during document creation, which one is >> authoritative? > > Repo-specific. > >> cmis:contentStreamMimeType is read-only. So, why should >> cmis:contentStreamFileName be read-write? >> And the other way round: If there is a reason to make >> cmis:contentStreamFileName read-write then cmis:contentStreamMimeType should >> also be read-write. > > See above. > >> Most repositories I have seen so far set cmis:contentStreamFileName to >> read-only. >> The change is more about clarity than spec compliance. > > Anyway our repo is happy to allow writes to cmis:contentStreamFileName > and as long as the OpenCMIS library doesn't prevent this use case I'm > happy. If in-memory wants to be restrictive then why not, but I still > don't see the point when the implementation is cheap. > > Florent > > >> >> >> Florian >> >> >> >> On 10/05/2011 16:22, Jens Hübel wrote: >>> Hmmm, >>> >>> looking at section 2.1.4.3.3 Property Definitions line 1357, I really don't >>> see that updatability is enforced as read-only. >>> >>> @Florian: Florian, I think you pointed out that the original implementation >>> does not behave correctly. Can you refer to the spec? Or did I >>> misunderstand and changed the wrong place? >>> >>> Jens >>> >>> >>> -----Original Message----- >>> From: Florent Guillaume [mailto:[email protected]] >>> Sent: Dienstag, 10. Mai 2011 16:37 >>> To: [email protected] >>> Cc: [email protected] >>> Subject: Re: svn commit: r1098638 - >>> /chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/types/DocumentTypeCreationHelper.java >>> >>> Why? >>> >>> On Mon, May 2, 2011 at 6:04 PM,<[email protected]> wrote: >>>> Author: jens >>>> Date: Mon May 2 16:04:49 2011 >>>> New Revision: 1098638 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=1098638&view=rev >>>> Log: >>>> make cmis:contentStreamFileName read-only for InMemory >>>> >>>> Modified: >>>> >>>> chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/types/DocumentTypeCreationHelper.java >>>> >>>> Modified: >>>> chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/types/DocumentTypeCreationHelper.java >>>> URL: >>>> http://svn.apache.org/viewvc/chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/types/DocumentTypeCreationHelper.java?rev=1098638&r1=1098637&r2=1098638&view=diff >>>> ============================================================================== >>>> --- >>>> chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/types/DocumentTypeCreationHelper.java >>>> (original) >>>> +++ >>>> chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/types/DocumentTypeCreationHelper.java >>>> Mon May 2 16:04:49 2011 >>>> @@ -194,6 +194,7 @@ public class DocumentTypeCreationHelper >>>> >>>> propS = >>>> PropertyCreationHelper.createStringDefinition(PropertyIds.CONTENT_STREAM_FILE_NAME, >>>> "CMIS Content Stream File Name Property"); >>>> + propS.setUpdatability(Updatability.READONLY); >>>> propertyDefinitions.put(propS.getId(), propS); >>>> >>>> propId = >>>> PropertyCreationHelper.createIdDefinition(PropertyIds.CONTENT_STREAM_ID, >>>> "CMIS Stream Id Property"); >>>> >>>> >>>> >>> >>> >>> >> >> > > > > -- > Florent Guillaume, Director of R&D, Nuxeo > Open Source, Java EE based, Enterprise Content Management (ECM) > http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87 > -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
