IMHO The spec is pretty clear on this (section 2.1.5.2): "Every folder object, except for one which is called the root folder, MUST have one and only one parent folder. The root folder does not have a parent.²
The question for me is also what you gain by hiding the id of the parent folder. The client knows that there must be a parent folder. You expose the path anyway and provide the client in this way a mechanism to retrieve the object using getObjectByPath(). I assume this results in a permission denied exception. What additional information is in the id that is worth to be hidden? And doesn¹t a file system behave also in a way that you see the parent but don¹t have access? Jens On 13/03/14 09:03, "Florian Müller" <[email protected]> wrote: > Hi Florent, > > The spec doesn't really clarify this case. > > Here is my personal gut feeling: > I think there should be an "up" link because every folder in CMIS must > have a parent folder. So a client could expect an "up" link. > Accessing the parent should throw a permissionDenied exception in your > case, though. I guess that would also match the behavior of the other > two bindings. > > > - Florian > > > >> Hi, >> >> In some of our applications a given folder (a user's workspace) has >> internally a parent that exists but is not accessible to the >> particular user. Therefore we return no parent for it. >> >> However Chemistry assumes that only the root can have no parent: >> org.apache.chemistry.opencmis.client.runtime.FolderImpl.getParents >> checks if it's not the root, and if not calls >> >> >>org.apache.chemistry.opencmis.client.bindings.spi.atompub.NavigationServi >>ceImpl.getFolderParent >> which fails as there's not rel="up" link. >> >> What do you think? Is what we do illegal according to the spec, or is >> it just Chemistry that has to be patched? >> >> Florent >
