1

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?

Nicolas Raoul
  • 58,567
  • 58
  • 222
  • 373

2 Answers2

1

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.

rotarydial
  • 2,181
  • 2
  • 23
  • 27
0

I do not think there are much restrictions on object names in a Documentum repository. If you want to apply a business rule to ensure no object names are created with the '/' character then have a look at the BOF framework.

Henning Winter
  • 46
  • 1
  • I know that Documentum allows slashes in object names, but my question was about how to handle such cases from the point of view of a CMIS client. Anyway, thanks for the business rule workaround! – Nicolas Raoul Oct 02 '17 at 03:21