OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [cmis] Scope of Hierarchical Properties

Hi, Jens,


Thanks for pointing out all these different aspects.  I encourage people to jump in to express their views and help define the scope of this "hierarchical/complex property" item.  It will be great if we can get our opinions out on the table before F2F.


If I am not mistaken, hierarchical/complex property so far is a "nice to have" capability.  It has not been identified as a "requirement" for v1.0, at least not yet.  We need use cases to help us to determine how important that we include hierarchical/complex property in v1.0, and if we do, what representation and operation are needed.  The use cases do not need to be "complete" since v1.0 is not meant to be a full-function interface. But they need to reflect importance.


Without imposing technical bias, I'd just mention that we should bear in mind the following considerations:


* Keep it simple for v1.0 (an objective that we discussed earlier), so long as the proposal does not inhibit future extension/generalization and allows backward compatibility.


* How does query handle hierarchical/complex properties?


* It needs to be easily layer-able on top of most repositories (an objective stated in the TC Charter).  This may lead to a "common denominator" solution.


Regarding "structured document", it may be a major topic by itself.  Some people think of them as content, such as large technical manuals that contain subcomponents.  Others think of them to contain metadata, such as forms.  And still others argue that content and metadata should be treated the same with no semantic distinction.  This discussion may touch upon XML and even XQuery.  The TC should decide whether we want to address this for v1.0.  In other words, we need to define the scope of "hierarchical/complex property" if we want to include it in v1.0.



From: Al Brown [mailto:albertcbrown@us.ibm.com]
Sent: Monday, December 15, 2008 11:28 AM
To: Jens Hübel
Cc: CMIS TC List
Subject: Re: [cmis] Scope of Hierarchical Properties


Thanks for sending this out. I think it is worthwhile to understand to how expose Pick List Dependencies, Language, Rendition, and Multi-Lingual. IBM has a repository that exposes #3 and others that do not. The older repositories tend not to support #3. The others are supported by patterns, best practices, and some different functionality across IBM's repositories.

Why don't we add to the agenda at the F2F discussion spots for the proposals as well as Choice List Dependencies, Language-variants, Rendition-variants and Multi-lingual support?


Al Brown
ECM CTO Staff, Information Managament
Office 714 327 3453
Mobile 714 263 6441
Email albertcbrown@us.ibm.com
CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation.

Inactive hide details for Jens Hübel ---12/12/2008 05:03:02 AM---Hi all,Jens Hübel ---12/12/2008 05:03:02 AM---Hi all,


Jens Hübel <jhuebel@opentext.com>


"CMIS TC List" <cmis@lists.oasis-open.org>


12/12/2008 05:03 AM


[cmis] Scope of Hierarchical Properties

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]