Hi, I would like to concur with Florian, I find what the OP describes a reasonable behavior for a server and I think all clients should be ready to accommodate for this possibility.
Florent On Wed, Aug 16, 2017 at 7:24 AM, Sascha Homeier <[email protected]> wrote: > Hi Florian, > > thanks very much for your detailed answer. > That eases things a lot for us ;) > > Cheers > Sascha > > P. +84 166 456-3331 > [email protected] > > turning technology. > > apollon GmbH+Co. KG > Maximilianstr. 104 > 75172 Pforzheim / Germany > www.apollon.de > > Geschäftsführer: Eugen Müller, Norbert Weckerle > Amtsgericht Mannheim HRA 705979 > PhG: apollon Verwaltungs-GmbH Mannheim HRB 720987 > > Besuchen Sie uns auf der dmexco Köln am 13./14. September 2017 > apollon gemeinsam mit implexis in Halle 7.1, Stand E-015 > Zur direkten Terminvereinbarung! > > On Aug 15, 2017, at 9:01 PM, Florian Müller <[email protected]> wrote: > > > > Hi Sacha, > > > > That's an interesting question. I don't think there is a definite answer. > > > > First of all, the server is the master of all (system) properties and > can change property values whenever necessary. > > The cmis:objectTypeId property is a bit different, though. The spec says > (section 2.1.2): "An object must have one and only one primary object-type, > which cannot be changed." > > That means, that the cmis:objectTypeId property can definitely not be > changed by clients and clients don't expect it to change during the > lifetime of an object. The spec disallows that a document can suddenly > become a folder. > > > > But your use case is different. You would change the cmis:objectTypeId > property _before_ the object is created. That is, the object type wouldn't > change during the lifetime of the document and that is in accordance with > the spec. You would also create a subtype of the requested type and not use > another base type. That is, the new document has all requested properties > and follows the requested CMIS behaviour. It's a super-set of the specified > type. > > I guess, most clients wouldn't notice it. I've seen servers that change > the name of a document at creation time to avoid name conflicts. That's > more confusing for clients than switching to a subtype. > > > > From a spec as well as from practical point of view, personally I would > put it into the category "acceptable". The term "valid" is very strong... > > > > > > - Florian > > > > > >> Hello together, > >> the CMIS 1.1 createDocument service “creates a document object of the > >> specified type (given by the cmis:objectTypeId property) in the > >> (optionally) specified location.” > >> Is it valid for the server to create a subtype of the given objectType? > >> The problem we currently face is that we map the Type-Hierarchy of our > >> DAM System 1:1 to the CMIS Type-Model. > >> Which means for example we have a type ‘omn:image’ which extends type > >> ‘omn:file’ which again extends type ‘cmis:document’. > >> So when we upload a file to our DAM system it automatically creates an > >> object of the proper type. For example, every upload of a *.jpg file > >> results in an object of type ‘omn:image’ while a *.zip would result in > >> ‘omn:file’. > >> We do not have any concrete objects of type ‘cmis:document’ but we > >> would like to allow the clients to create a document of this type for > >> convenience purposes. > >> Because > >> 1.) many CMIS Clients just use ‘cmis:document’ by default when > creatingDocuments > >> 2.) otherwise the client needs to know the required typeId for every > >> file type he wants to create > >> So, if the client asks to create a document of type “cmis:document” > >> and the server creates this document but it is of type ‘omn:image’ > >> (which is a subtype of 'cmis:document'), would this be valid CMIS? > >> P.S: > >> Lesson Learned: Composition over Inheritance <-> > >> Aspects/SecondaryTypes over complex Hierarchies ;) > >> Thx in advance. > >> Cheers > >> Sascha > >> P. +84 166 456-3331 > >> [email protected] > >> turning technology. > >> apollon GmbH+Co. KG > >> Maximilianstr. 104 > >> 75172 Pforzheim / Germany > >> www.apollon.de > >> Geschäftsführer: Eugen Müller, Norbert Weckerle > >> Amtsgericht Mannheim HRA 705979 > >> PhG: apollon Verwaltungs-GmbH Mannheim HRB 720987 > >> Besuchen Sie uns auf der dmexco Köln am 13./14. September 2017 > >> apollon gemeinsam mit implexis in Halle 7.1, Stand E-015 > >> Zur direkten Terminvereinbarung! > > -- [image: Nuxeo] Florent Guillaume Head of R&D Twitter: @efge
