Thanks for SAP KM and JCR.
>The main reason to have it seems to be that you can make a multivalued property mandatory,
>and still allow it to be empty.
How is that different than optional multi-valued property with a choice list? (Beyond the basic optional -> mandatory property flag)
>It probably doesn't make a big difference in practice...
If it is not a big difference in practice, why should it be added and add to the complexity/cost of CMIS?
I try to use 80% as a filter - if 80% of repositories support it or if 80% of targeted applications on repositories require the functionality. Simplicity and ease of implementing (client and app) will be key to the success of this effort.
-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.
Julian Reschke ---04/08/2009 01:47:28 PM---Florent Guillaume wrote:
From:
Julian Reschke <>
To:
Florent Guillaume <>
Cc:
Date:
04/08/2009 01:47 PM
Subject:
Re: [cmis] empty multivalued properties
Florent Guillaume wrote:
> 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.
Well, some do (such as SAP KM, predating JCR, and every conforming JCR
implementation). Some don't.
> 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.
I agree that JCR's behavior is harder to implement. The main reason to
have it seems to be that you can make a multivalued property mandatory,
and still allow it to be empty. It probably doesn't make a big
difference in practice...
Al Brown wrote:
> ...
> 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.
> ...
Well, exactly what the JCR spec says (it's quite clear on that, methinks).
(Keep in mind that we're talking about multivalued properties only).
BR, Julian
--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782
---------------------------------------------------------------------
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
