CODEWITHSUNDEEP
cmisdocumentum
Nicolas Raoul
Nicolas Raoul

Reputation: 60213

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?

Upvotes: 1

Views: 494

Answers (2)

rotarydial
rotarydial

Reputation: 2591

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.

Upvotes: 1

Henning Winter
Henning Winter

Reputation: 46

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.

Upvotes: 0

Related Questions