OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

[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]