Search code examples
cmisdocumentum

Slash in cmis:name and cmis:contentStreamFilename

The CMIS 1.1 specification says:

2.1.5.3 Paths
A folder hierarchy MAY be represented in a canonical notation such as path. [...]
A pathSegment token MUST not include a ’/’ character.
It is repository specific how a repository chooses the value for pathSegment. Repositories might choose to use cmis:name or content stream filename for pathSegment token.

But, I was able to create the document below in a Documentum 7.1.0000.0146 server:

Documentum in CMIS Workbench

As you can see, both cmis:name and cmis:contentStreamFilename contain a slash. Actually, it seems that cmis:contentStreamFilename becomes whatever cmis:name is (plus the extension).

Is this a bug in Documentum's CMIS implementation?

While this server replies correctly to "normal" getObjectByPath requests with cmis:name path elements, is there any way to use getObjectByPath for the object in the screenshot above? Or is getObjectByPath unusable with such a server?

Solution

  • I do believe it is a bug in Documentum's CMIS implementation (meaning, it's a bug to allow the slash to be part of cmis:name and cmis:contentStreamFileName). I found this bug report from the Apache Chemistry Jira project, where it seems a similar bug was fixed. Some comments that shed some light on the issue:

    Given the following path to an object: /a/b/c/d.pdf

    The path segment tokens are "a", "b", "c", and "d.pdf".

    The getObjectByPath method does assume that you will pass it a path comprised of path segment tokens separated by forward slashes. This is how CMIS defines a "path" per the spec.

    ...and...

    Repository might use cmis:name for pathSegment token, however, if repository doesn't use cmis:name as pathSegment token, this case will fail obviously.

    There're some possible scenarios that cmis:name is not used as pathSegment token:

    1) Content stream file name is used rather than cmis:name as it is described in the spec.

    2) Repository supports to create document with same cmis:name in a folder, which means it is inevitable to use other value rather than cmis:name as its pathSegment since "The pathSegment token for each item MUST uniquely identify the item in the folder" according to the spec.

    I don't know Documentum specifically, so whether this bug would manifest when fetching the object is a coin toss. Have you considered using CMIS Workbench to run a simple CMIS query to find it using one of those properties? If it worked, I'd be pretty confident (though not 100%) it would work with getObjectByPath.