You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@chemistry.apache.org by Sascha Homeier <sh...@apollon.de> on 2017/08/15 12:28:31 UTC

createDocument Service: Valid CMIS Behaviour

Hello together,

the CMIS 1.1 createDocument service “creates a document object of the speciﬁed type (given by the cmis:objectTypeId property) in the (optionally) speciﬁed 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!

Re: createDocument Service: Valid CMIS Behaviour

Posted by Florent Guillaume <fg...@nuxeo.com>.

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 <sh...@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 <fm...@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 speciﬁed
> 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
> >> speciﬁed type (given by the cmis:objectTypeId property) in the
> >> (optionally) speciﬁed 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

Re: createDocument Service: Valid CMIS Behaviour

Posted by Sascha Homeier <sh...@apollon.de>.

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 <fm...@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 speciﬁed 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
>> speciﬁed type (given by the cmis:objectTypeId property) in the
>> (optionally) speciﬁed 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!

Re: createDocument Service: Valid CMIS Behaviour

Posted by Florian Müller <fm...@apache.org>.

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 speciﬁed 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
> speciﬁed type (given by the cmis:objectTypeId property) in the
> (optionally) speciﬁed 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!