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.
david
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
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.
Jens Hübel
---12/12/2008 05:03:02 AM---Hi all,
|
|
|
|
|
|
|
|
|
|
|
|
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