Scope of Hierarchical Properties

[Jens Hübel <jhuebel@opentext.com>]

Hi all,

 

as the first step of the assigned task to specify a potential CMIS extension for hierarchical properties we should discuss the scope of this. For me this term is not very precise and I guess we need some clarification on this before we can start writing down the proposal.

 

To start this discussion I will come up with a list of use cases. This list is not complete and I encourage all members of the TC to contribute here.

 

1.      Dependent Pick Lists

Sometimes properties have a hierarchy between each other. You might have a list of car manufactures on first level and a list of car models on the second level where the allowed elements depend on the value of the first level.

 

2.      Structured documents

Many repositories allow documents not being modeled as something flat but having structure within the document itself. CMIS does support versions as a substructures, other repositories might have additional structures like sub-components, languages, renditions, attachments, whatever. Often repositories allow properties on document level as well as on component level. Some properties might have a global scope (like name, status), whereas other properties might depend on the component level (version-specific, language-specific, attachment specific), e.g author, modificationDate. The structure is not necessarily restricted to two levels, but can be a tree (e.g. Document-Version-Language-Rendition).

 

3.      Relationship within properties

Some repositories allow properties to be grouped and have a structure in itself. A invoice might have a an ordered list of items, each item having an amount. This is a kind of relationship on property level. The CMIS relationship service might be a way to deal with those situations.

 

4.      Multilingual properties

Perhaps a special form of a hierarchy, but could have some common pattern. Allow a value of a property to be available in more than one language, for example a comment field in English and French.

 

If I remember correctly use case 2 was the trigger for this discussion. So the main questionsfor me are:

 

What are the most important use cases?

How wide are those concepts in use for given repositories?

How big is the need to have this standardized in version 1.0 of the standard?

What would be the important aspects to be part of standard?

What is a generic application supposed to do with this?

 

For OpenText we support 2 and 3 in our main repository. I would see some demand for scenario 2 and would consider 3 being less important for the first version. 4 is planned. For 2 however this would not be restricted to properties but to content as well.

 

How far do we want to go and still preserve the current CMIS principles?

Any ideas how to extend the spec in this regard are of course welcome too.

 

Jens