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