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: How to handle the "same" properties defined in primary and secondary types?
Date Fri, 02 Jun 2017 19:39:08 GMT
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
> 
> 

Mime
View raw message