[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (CMIS-591) Clarification forhierachical properties needed
[ http://tools.oasis-open.org/issues/browse/CMIS-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ethan Gur-esh updated CMIS-591: ------------------------------- Resolution: I've updated section 2.1.3.3.2 with more text explaining that the choice values are "individual" values, and added a hierarchical property example as suggested. (was: I've updated section 2.) Assignee: Jens Hübel (was: Al Brown) > Clarification for hierachical properties needed > ----------------------------------------------- > > Key: CMIS-591 > URL: http://tools.oasis-open.org/issues/browse/CMIS-591 > Project: OASIS Content Management Interoperability Services (CMIS) TC > Issue Type: Improvement > Components: Domain Model > Affects Versions: Draft 0.70 > Reporter: Jens Hübel > Assignee: Jens Hübel > Priority: Minor > Fix For: Committee Draft 05 > > > Summary from discusion on the mailing list: > Property definitions can be a) hierachical and b) multi-value > We need to clarify how a repository should/can behave here and what the intended use case is: > One possible interpretation: > 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." > Possible interpretation A: > For multi valued properties each choice is designed to be again a list of values. 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"} > Possible Interpretation B: > 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. > 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. > Suggest to make B the recommended way (SHOULD?) and others optional (MAY) > Suggest to add an XML dump for B as example to our spec -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]