chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florent Guillaume <fguilla...@nuxeo.com>
Subject Re: createDocument Service: Valid CMIS Behaviour
Date Wed, 16 Aug 2017 12:36:53 GMT
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 <shomeier@apollon.de> wrote:

> Hi Florian,
>
> thanks very much for your detailed answer.
> That eases things a lot for us ;)
>
> 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!
> > On Aug 15, 2017, at 9:01 PM, Florian Müller <fmui@apache.org> 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
> >> 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!
>
>


-- 
[image: Nuxeo]

Florent Guillaume
Head of R&D

Twitter: @efge

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message