chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Hübel <>
Subject RE: Not set properties
Date Wed, 12 Oct 2011 22:13:33 GMT
Thanks for clarification! Good to know that it already has been fixed in the spec.

-----Original Message-----
From: Florian Müller [] 
Sent: Mittwoch, 12. Oktober 2011 23:35
Cc: Jens Hübel
Subject: Re: Not set properties

Hi Jens,

It has been clarified in the CMIS 1.0 errata [1].

If no property filter is set, the repository decides which properties to return. It could
decide not send version properties for non-versionable documents.
If the property filter is set ("*" or property list), then the client is responsible for all
bandwidth waste.

- Florian


----- Original Message -----
From: "Jens Hübel" <>
Sent: Wednesday, October 12, 2011 9:33:12 PM GMT +00:00 GMT Britain, Ireland, Portugal
Subject: RE: Not set properties

Hi Chemistries,

I am just reading through this older thread here. 

> -----Original Message-----
> From: Florian Müller [] 
> Sent: Montag, 22. August 2011 15:58
> To:; Weigel, Achim
> Subject: Re: Not set properties
> Hi Achim,
> Not-set properties have to be returned (see CMIS spec). There must be a PropertyData
object for each property. The value can be either null or an empty list. OpenCMIS understands

Can someone point me to the relevant section in the spec that not set properties have to be

If a value is not provided for a property, the property is in a "value not set" state. There
is no "null" value for a property. Through protocol binding, a property is either not set,
or is set to a particular value or a list of values.  

4.2 Web Services Binding Mapping 
Optional parameters and optional return values are not set if they are missing or their value
is NULL.

Do I read the first section correctly that this is binding specific? Do I read the second
section correctly that this is optional for web services? 

I feel I missed finding the relevant phrase, but where is it? And does someone recall the
motivation behind that? There are use case where you may have dozens of properties on a type
where only few of them are actually used. This is a huge waste of network bandwidth then.
Why do I have to return all the irrelevant versioning properties if my repository implementation
does not even support versioning? Does this make sense? And should we change something or
make this more explicit in the CMIS spec for 1.1?


P.S. At some point we should think about creating a FAQ...
View raw message