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!
