Hierarchical Properties

Possible Features

Dependent Pick Lists
Structured Documents
Relationship within properties
Multilingual properties

More detail here http://lists.oasis-open.org/archives/cmis/200812/msg00041.html

Other references here: Scope of Hierarchical Properties

Comments

worthwhile to understand to how expose Pick List Dependencies, Language, Rendition, and Multi-Lingual.
Relationship within properties only in some (few?) repositories
others by patterns and best practices
nice to have for 1.0 not a requirement up to now
looking for use cases do determine importance of this
should focus only on most important functionality for 1.0

Suggestions

A possible model could be:

   property = single-valued-property | multi-valued-property | list- 
property | map-property

   single-valued-property = (the one in CMIS 0.5)
   multi-valued-property = (the one in CMIS 0.5)
   list-property = list of map-property with identical schemas
   map-property = map of key -> property obeying to a fixed schema

This roughly the model that Nuxeo uses. It allows for the representation of structures like (JSON):

{ "title": "Report on use of automobiles",
   "subject": ["cars", "transportation"],
   "authors": [{"firstname": "Bob", "lastname": "Smith"},  
{"firstname": "Pete", "lastname": "Wu"}]
}

Relations to other standards

JCR

does not natively support hierarchies in properties but instead a hierarchy of nodes, structure is in the hierarchy of nodes
(+) flexible
(+) solves query
(-) hard to implement for repositories not supporting such a concept

WebDAV

properties can be XML

(+) extremely easy to implement (in simpels case jus a string)
(-) only accessible and access-controlled in total
(-) no good solutions for query

open topics / things that need to be discussed

how to integrate in this query
preserve design principle: CMIS to be implementable on top of existing repositories
structured documents very complex topic for itself
define relationship with XML / xquery
do we need namespaces

Use Cases

Thumbnails

After loading a document into a CMIS enabled repository it would be great to have an CMIS application add a number of thumbnails in various sizes into a "thumbnail" structure. Since the thumbnails themselves semanticly should not be treated as an individual document, since this would clutter the namespace the thumbnails should be treated as structured meta-data.

Persisting and Querying XMP

Since many modern file formats (PDF, JPEG, ...) support XMP data upon ingestion the XMP information could (probably should) be extracted by a repository (or any thirdparty CMIS app). This should be done in a fashion that allows for query of the respective information, since of course XMP holds a wide variety of potentially very useful information. more general: how to map RDF from/to CMIS/JCR/WebDAV

[DavidC] If extracting XMP data is all that is needed, would it be easier to invoke a utility outside CMIS for that purpose? Otherwise, what file formats a CMIS-provider is be required to interpret and extract metadata? On the other hand, if XMP metadata remain embedded in a file (as a part of the CMIS abstract data model), how should query work?

Discussion

Some comments that came up during conf call on Dec-17th-2008 (only few participants):

Relation to name spaces
Some tendency to postpone the whole topic for a later spec release than 1.0
If postponed must ensure backwards compatibility
Some tendency in prioritization of multilingual, version specific properties, dependent pick lists, array and map types, but not of structured/complex documents and relations