[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]