You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Vyacheslav Pascarel <vp...@opentext.com> on 2017/06/09 15:49:10 UTC

RE: [EXTERNAL] - Re: How to handle the "same" properties defined in primary and secondary types?

Thanks Florian. 

That was my interpretation/understanding of CMIS as well but Alfresco implementation got me confused.

Vyacheslav Pascarel


-----Original Message-----
From: Florian Müller [mailto:fmui@apache.org] 
Sent: Friday, June 2, 2017 3:39 PM
To: Vyacheslav Pascarel <vp...@opentext.com>; dev@chemistry.apache.org
Subject: [EXTERNAL] - Re: How to handle the "same" properties defined in primary and secondary types?

Hi,

The CMIS spec doesn't specially cover this topic. However, my interpretation of section 2.1.9 is that secondary properties and primary properties should not overlap:

"A secondary type defines a set of properties that can be dynamically added to and removed from objects. That is, an object can get and lose additional properties that are not defined by its primary type during its lifetime."

Technically, that doesn't matter iff the property definitions in primary and secondary types are the same and only one value is returned for this property. If this property appears twice on an object, I would consider this a bug.

OpenCMIS internally uses a map to handle the properties. Therefore, there can only be one value per property. If the repository returns two, it is undefined which one is chosen.


- Florian



> Hello,
> 
> My application consumes Alfresco CMIS services and I noticed that many Alfresco primary and secondary types have a lot of overlapping  properties. For example "cmis:objectId" property appears in "cmis:document" primary and "P:rn:renditioned" secondary type definitions. The former secondary type can be applied to objects of "cmis:document" type. When applied, Alfresco returns two identical "<cmis:propertyId...>" entries in AtomPub response for "cmis:objectId" property. Apache Chemistry Workbench still works and shows only one occurrence of such properties.
> 
> So my questions are:
> 
> -          Is Alfresco behavior "compliant" with CMIS 1.1 in sense of having the "same" property defined in primary/secondary types?
> 
> -          If YES, then what assumptions are correct:
> 
> o   A "duplicated" property definition should be identical across all the type definitions
> 
> o   A "duplicated" property definitions should at least have a compatible "value" type
> 
> o   A "single" property value is "shared" across primary and secondary types in object "instance" (the property may appear multiple times in request/response but only one occurrence is respected)
> 
> -          If NO, then what assumptions are correct:
> 
> o   As a workaround: only first or last value should be respected for object containing "duplicated" properties
> 
> o   A "duplicated" property should be treated according to its definition in "primary" type
> 
> Thank you in advance,
> 
> Vyacheslav Pascarel
> 
>