I agree.
I'd like to keep this simple and unless the majority of repositories support not set, set: null/empty, and set: value. Right now CMIS does not have a notion of null only set and not set. I'd also like to understand better what set: null/empty means compared to not set.
-Al
Al Brown
Emerging Standards and Industry Frameworks
CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home
Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home
Office 714 327 3453
Mobile 714 263 6441
Email
CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation.
Florent Guillaume ---04/08/2009 08:43:47 AM---On 3 Apr 2009, at 15:19, Julian Reschke wrote:
From:
Florent Guillaume <>
To:
Julian Reschke <>
Cc:
Date:
04/08/2009 08:43 AM
Subject:
Re: [cmis] empty multivalued properties
On 3 Apr 2009, at 15:19, Julian Reschke wrote:
> looking at the Domain Model 0.6, Section 2.2.1:
>
> "A multi-valued property is either set or not set in its entirety.
> An individual value of a multi-valued property SHALL NOT be in an
> individual “value not set” state and hold a position in the list of
> values. An empty list of values SHALL NOT be allowed."
>
> This is a really unfortunate mismatch with JCR, where repositories
> MUST support empty multivalued properties.
>
> Is this really necessary? Could the behavior be made optional?
In most uses cases I have, an empty list can be modeled by having the
property not set. This is enough for me, but I agree that the JCR
model for instance is more complex than that.
I guess many existing repositories just don't support empty lists as a
different value than null.
There's no easy solution, one model is richer than the other.
In any case I wouldn't want to see this be an optional behavior. The
spec should specify one or the other.
Florent
--
Florent Guillaume, Head of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
