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: [OASIS Issue Tracker] Created: (CMIS-556) Folder Tree andDescendants DELETE need clarification

Folder Tree and Descendants DELETE need clarification

                 Key: CMIS-556
                 URL: http://tools.oasis-open.org/issues/browse/CMIS-556
             Project: OASIS Content Management Interoperability Services (CMIS) TC
          Issue Type: Bug
          Components: REST/AtomPub Binding
    Affects Versions: Draft 0.70
            Reporter: Ryan McVeigh
            Assignee: Al Brown

8.3.2 DELETE
  "If the delete method does not delete all items, invoking GET on the URI will return the items not deleted"
    should say "with infinite depth (-1)"?
    How does this work if capabilityGetDescendants or canGetDescendants is false for this folder?

From Al:  Not sure this should be in the specification. but the quick answer is either 'repository specific' or 'it doesn't'

8.4.2 folder tree DELETE
  This resource represents the folder tree - why does DELETE also delete objects and not just folders?

From Al:  It's the same as delete descendants which is the deleteTree service in p1. Not sure how to delete folders if you don't deal with the things in them.

Because of the way these resources are specified, I am not sure that we can meet the domain model intent for a couple of issues:
1)  deleteTree is supposed to return a list of undeleted objects.  The AtomPub binding tries to do this by saying you just call folderDescendants if the delete doesn't succeed.  However, for this binding (only) there is now a link between canDeleteTree and canGetDescendants/capabilityGetDescendants.  You must be able to getDescendants to fully implement the domain model's service for delteTree.  Our repo can implement the deleteTree, but not getDescendants - so we are forced now to also not implement deleteTree?
2) It is not clear to me - can the resource be exposed for only DELETE and not GET (for the case where canDeleteTree=true but capabilityGetDescendants=false)?
3) Having two ways to delete is confusing - what if your repository has capabilityGetTree but not capabilityGetDescendants (or the other way round) - the client has to use that to figure out which resource might be available for delete?
4) The DELETE method says "invoking GET on this URI will return items not deleted".  Even if both capabilities are true, this is not true when "this resource" is the folderTree, as some of the undeleted resources might be non-folders.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


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