chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller <f...@apache.org>
Subject Re: createDocument Service: Valid CMIS Behaviour
Date Tue, 15 Aug 2017 14:01:30 GMT
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
> shomeier@apollon.de
> 
> 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!

Mime
View raw message