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

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

     [ 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.
      Assignee: Al Brown  (was: Ethan Gur-esh)

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