Re: [cmis] Scope of Hierarchical Properties

[Florent Guillaume <fg@nuxeo.com>]

Hi everyone,

I'll talk here about what my vision of "complex properties" is based  
on the use cases that Jens described. Then I'll comment on what I  
would like to see for CMIS 1.0.


On 12 Dec 2008, at 14:00, Jens Hübel wrote:
> 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.

This is indeed hierarchical but that's not what I imagined we were  
talking about when mentioning "complex properties".

For me the use case here is answered by a simple string-based property  
of the form "manufacturer/model" for instance. If a search on 'ford'  
should also find all strings of the form 'ford/somemodel' then a query  
for "field = 'ford' OR field LIKE 'ford/%'" works well.
For tag clouds, an alternate model based on multi-valued properties  
that store both 'ford' and 'ford/pinto' can also be considered,  
depending on the expected uses.

How do other repositories implement this use case at the storage 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).

For me this is, for the most part, the perfect use case for  
relationships. An alternate language or an alternate rendition can be  
another document in relation with the main one. Some standard  
relationship types for this across repositories for "language" or  
"rendition" could be defined, but I fear that's already beyond what is  
wanted for CMIS 1.0.

Versions are a bit special because they are tied to the PWC notion and  
to the fact that in some repositories the "last" version is  
automatically chose in some cases (folder listing).

For the renditions, and for thumbnails mentioned by David N., in some  
cases a storage based on alternate content streams would also be quite  
useful. This what Nuxeo uses for thumbnails, otherwise Nuxeo uses  
relations (similar to relationships).

> 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.

This is what I understood "complex properties" were.

A model I would suggest would 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"}]
}
with arbitrary depth.


> 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.

That's also an important use case but for which I don't have a  
canonical answer. I'm also curious of how most repositories would  
implement this use case.


If all this could be standardized accross vendors that would be great,  
however I'd much rather have the current spec be standardized as is  
without adding complex/hierarchical properties than delay the release  
while we hash out what we really want there. We can always do a CMIS  
2.0 later, for me what's important is that there already be a CMIS 1.0  
that's accepted by the public to base it on.

Regards,
Florent

-- 
Florent Guillaume, Head of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87