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 > >
