Hi Jorge,
I don't understand your issue. The OpenCMIS client library translates null
values into empty lists, which are from the CMIS spec perspective "not set"
values.
It is valid to set the property values of cmis:description and
cmis:secondaryObjectTypeIds to "not set" if the properties are not read-only.
Since both, the origin and the new document, are of the same type, the same
rules should apply. If the origin document can have a "not set"
cmis:description, the new document should allow that as well.
Or did I miss something?
- Florian
> Good morning,
>
> I have seen that the TCK test CopyTest was ignored in the past for AtomPub
> binding, and now the DocumentImpl is implementing a "client-copy" executing a
> create document.
>
> My issue is that that the piece of code that is copying the properties is
> considering cmis:description and cmis:secondaryObjectTypeIds,
> and both of them are empty.
>
> for (Property<?> prop : allPropsDoc.getProperties()) {
> if (prop.getDefinition().getUpdatability() == Updatability.READWRITE
> || prop.getDefinition().getUpdatability() ==
> Updatability.ONCREATE) {
> newProperties.put(prop.getId(), prop.getValue());
> }
> }
>
> From CMIS 1.1 spec (2.1.2.1 Property)
> […]
> CMIS does not support "null" property value. If a multi-valued property is not
> in a "not set" state, its property value MUST be a non-empty list of
> individual values.
> […]
> In our ObjectService.createDocument() implementation we are validating that
> the property values are not empty.
>
> Could you please consider changing the code to only copy properties with
> values?
> Regards.
> Jorge MARTIN CUERVO
> [cid:image001.gif@01CCF6D0.4613B970]
> European Commission
> DG TRADE
> Unit A4
> CHAR 02/077
> B-1049 Brussels/Belgium
> +32 2 298 86 27
> jorge.martin-cue...@ext.ec.europa.eu<mailto:jorge.martin-cue...@ext.ec.europa.eu>
>
