[OASIS Issue Tracker] (CMIS-778) CMIS Extension: Dependent Objects

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/CMIS-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43850#comment-43850 ] 

David Choy commented on CMIS-778:
---------------------------------

Below are my notes for today's discussion on Dependent Object. Feel free to add more.

The concept to be modeled:

A dependent object is an object whose existence depends on the existence of another object which is henceforth called the parent object of this dependent object. If the parent object is deleted, all its dependent objects must be automatically deleted by the repository. A dependent object may provide additional information describing its parent object, but is not considered a part of the parent object. Therefore, creating, updating, or deleting a dependent object is not considered an update of its parent object. This semantics should be reflected in the versioning, access control, query, and other functions for the dependent object and for its parent. The parent object may itself be a dependent object which depends on yet another object. But there can be no cycle in the dependence relationship graph in the repository.

Some issues on the current proposal:

- How is a dependent object created?
Created from scratch (perhaps adding a new "dependentObject" flag to the createXXX services which would add the dependent object secondary type to the new object), or created by adding the dependent object secondary type to an existing object (Do we want to keep this second option open? For the latter, how do we enforce constraints on dependent object, on comment, on annotation, etc, e.g. no content stream for a Comment? Any ad hoc rules here would look like a bandage.)? What should the updatability of the parent object id be? Currently it is "readonly", why? If a dependent object can only be created from scratch, then the updatability should be "onCreate".

- Is there a use case for the removal of the dependent object secondary type from an object?

- Should we define a single parent for a dependent object and add another parent for a Comment? Should we define parent id as a multivalued property instead? If multivalued, do we need to define the semantics for the first parent, the second parent, etc? Should there be referential constraint on the immediate parent as well? Some repositories may not be able to support referential integrity. Multiple RI on the same object would be even harder to support. Should there be any relationship constraint between the root parent and the immediate parent (e.g. for the Comments use case, the immediate parent should be either the root parent or a dependent object having the same root parent)?

- If a parent object is versionable, should the dependent object depends on a specific version of the parent or all versions of the parent? There may be use cases for both. For the latter, the "latest state" object id of the parent may be used as the reference, and the dependent object must be deleted by the repository when all versions of the parent are deleted. This may be hard for some repositories to support.

- On access control, there are use cases for inheriting ACL from parent (which parent?) and use cases for the dependent object to have its own ACL (e.g. a private comment). Clients like to have an ability to choose. Repositories on the other hand may have difficulty to support ACL inheritance. One possibility is to let client either create an ACL for the dependent object or instruct the repository to copy the ACL from one of its parents. No inheritance capability is required with this approach.


> CMIS Extension:  Dependent Objects
> ----------------------------------
>
>                 Key: CMIS-778
>                 URL: https://issues.oasis-open.org/browse/CMIS-778
>             Project: OASIS Content Management Interoperability Services (CMIS) TC
>          Issue Type: New Feature
>          Components: Domain Model
>    Affects Versions: Proposals for 2.0
>            Reporter: Jay Brown
>            Priority: Minor
>
> Forked from CMIS-759 
> Specification
> A dependent object has two defining characteristics:
> ­ it MUST have a reference to some parent object
> ­ it is automatically deleted when the parent is deleted
> This record will host just the Dependent Object extension discussion and details. 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)