chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Jorge.MARTIN-CUE...@ext.ec.europa.eu>
Subject RE: TCK: CopyTest with AtomPub
Date Tue, 19 Aug 2014 15:31:18 GMT
Hello Florian,



thanks for your comments, I am agreed that sending "empty" or better called "not-set" variables
should be valid CMIS.



I will remove the validation code and ignore the empty properties.

In any case if the repository consumers wants an exception when a property is empty, they
could define this property as required.



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-cuervo@ext.ec.europa.eu<mailto:jorge.martin-cuervo@ext.ec.europa.eu>



-----Original Message-----
From: Florian Müller [mailto:fmui@apache.org]
Sent: Tuesday, August 19, 2014 11:12 AM
To: MARTIN CUERVO Jorge (TRADE-EXT); dev
Subject: Re: TCK: CopyTest with AtomPub



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-cuervo@ext.ec.europa.eu<mailto:jorge.martin-cuervo@ext.ec.europa.eu<mailto:jorge.martin-cuervo@ext.ec.europa.eu%3cmailto:jorge.martin-cuervo@ext.ec.europa.eu>>

>
Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message