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: 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

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]