Thanks to all of you helping clarifying this. I think we have to
make this more precise in the spec. I am not sure that everyone can extract the
intended use case from what we have there. I will file a JIRA issue for this
(unfortunately I will miss the TC call on Monday Novt 9th).
From my perspective “Al’s” use case with the hierarchical model
is much more common than “mine”. It makes perfect sense for single values. In
case for multiple values I see a use case if in Al’s example we would have a
list of cities allowed.
So what I would like to see in the spec is somehow that a
repository SHOULD behave in a way like Al describes and other models MAY be
allowed (personally I do not see much value in those, but probably we should
not enforce it).
Making Al’s suggestion as an example in our spec collection
would help a lot here.
Jens
From: Choy_David@emc.com
[mailto:Choy_David@emc.com]
Sent: Freitag, 6. November 2009 03:23
To: albertcbrown@us.ibm.com; paul.goetz@sap.com
Cc: cmis@lists.oasis-open.org; Jens Hübel
Subject: RE: [cmis] RE: How should multi-valued choice lists be checked?
Looks like clarification is needed in the
spec.
When ordering of choice values was
originally introduced, it was meant for display purpose only. I do not recall
any proposal to use it also as an ordering constraint for multi-value. Unless
someone propose to make this a CMIS-imposed constraint, it is probably best
left as a repository-specific constraint if this is indeed enforced by some
repositories.
A bigger issue is that there seem to be two
ways to specify choices for a multi-valued property.
[Jen’s model] A multi-value is considered a
single list-value. An application must make a single choice among several
allowable list-values.
[Al’s model] A multi-value is considered a
list of single values. An application is expected to make multiple selections
from a set of allowable single values.
The two models are not the same. Shall we
support both? If both are supported by the spec, a choices specification then
must syntactically distinguish between a single value and a list value, and
must not allow a mixture of both in choices. However, a repository
implementation can restrict a choices specification to one of the two forms
since type definition is outside CMIS.
david
From: Al Brown [mailto:albertcbrown@us.ibm.com]
Sent: Thursday, November 05, 2009 4:32 PM
To: Goetz, Paul
Cc: cmis@lists.oasis-open.org; Jens Hübel
Subject: Re: [cmis] RE: How should multi-valued choice lists be checked?
If I now pass a
ColorModel property with a value of {“blue”, “green”, “red”} in a create…()
call. Is this an allowed value or should a ConstraintViolation be thrown in
this case?
Al - I would
leave this to the repository and not mandate either way on the specification.
Primarily I
guess ordering is intended in this context how to display the sequence in a UI.
But is it also to be used for constraint checking and is it meant to be
“recursive” in this case?
Al - I do
not believe so. It was mainly meant to express if a repository supports
multi-valued choice lists a way of expressing them. I believe all behavior if
not obvious is repository specific.
How do
others have implemented this? Does this need clarification in the spec? I am
not sure if we should make something repository specific on this level.
Al - Our
model is slightly different from yours displayed. Choice lists can be
hierarchical such as (Country) -> (State/Region) -> City and mostly used
with single value properties (e.g., only one item selected). If used with
multi-valued properties, then multiple single elements can be chosen.
-Al
Al Brown
Office 714 327 3453
Mobile 714 263 6441
Email albertcbrown@us.ibm.com
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.
"Goetz, Paul" ---11/04/2009 10:07:35 AM---Hi
Jens, since I lack any deep knowledge about this, I would simply assume the
following: Ordering i
From: "Goetz, Paul"
<paul.goetz@sap.com>
To: Jens Hübel <jhuebel@opentext.com>
Cc: "cmis@lists.oasis-open.org"
<cmis@lists.oasis-open.org>
Date: 11/04/2009 10:07 AM
Subject: [cmis] RE: How should multi-valued choice
lists be checked?
Hi
Jens,
since
I lack any deep knowledge about this, I would simply assume the following:
Ordering is something for the client.
Thus:
a)
the ordering provided by the client should be preserved by the server. in your
case the provided ColorModel property value on create...() should result in the
same value being returned by the server on consecutive get...() calls. That's
what I would consider as "explicit ordered" (by the client).
b)
the ordering should not be used as constraint on the server side. (if there are
such constraints, then this would be something repository specific and not be
expressed in the CMIS model, at least for my understanding).
At
least that's the way SAP KM implemented it... :o)
Best
regards,
Paul
From: Jens Hübel [mailto:jhuebel@opentext.com]
Sent: Mittwoch, 4. November 2009 18:43
To: cmis@lists.oasis-open.org
Subject: [cmis] How should multi-valued choice lists be checked?
Hi all,
the spec
says for choice lists (1.0D4, 2.1.3.3.2):
“Choices:
Indicates an explicit ordered set of values allowed for this property.”
For multi
valued properties each choice is designed to be again a list of values. However
the meaning of “explicit ordered” is not clear to me in this context. Let’s say
I have a string property definition ColorModel of cardinality MULTI with two
choices
Choice[0]
={“red”, “green”, “blue”}
Choice[1]
={“cyan”, “magenta”, “yellow”, “black”}
If I now
pass a ColorModel property with a value of {“blue”, “green”, “red”} in a
create…() call. Is this an allowed value or should a ConstraintViolation be
thrown in this case?
Primarily I
guess ordering is intended in this context how to display the sequence in a UI.
But is it also to be used for constraint checking and is it meant to be
“recursive” in this case?
How do
others have implemented this? Does this need clarification in the spec? I am
not sure if we should make something repository specific on this level.
(Sorry for
the bad example, of course you would normally make this a single valued choice
property: RGB, CMYK, but I don’t have a better one at the moment)
Thanks for
any hint
Jens