[OASIS Issue Tracker] Created: (CMIS-591) Clarification forhierachical properties needed

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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: Ethan Gur-esh
            Priority: Minor


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