nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Why createDocument makes different path segment then document name?

ZoranV

When creating document by ObjectService createDocument, its path segment takes objectId_documentName format. Other Content Management Systems I have tested (IBM Content Manager, MS SharePoint) using CMIS, make path segment in format documentName, which seems more logical to me.

Sample C# code:

string

cmisObjectId = objectService.createDocument(repositoryId, properties, parentFolderId, contentStream, null, null, null, null, ref extension);

This behavior has side effects:1) When creating document, allways new document is created (with different name). "Document allready exist" scenario never happens. 2) ObjectService getObjectByPath operation will not work as expected. When invoked with parent_folder_path/document_name, it will not return document as expected.

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Button

Accepted answers

abc123

Thanks for the good catch. CMIS spec very carefully choose the word MUST, SHOULD or MAY and each vendor is sensitive at it.

According to RFC2119, MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.

So I don't think it a bug

William

Inbox.GIF

All comments

abc123

This is because multiple documents with the same name can co-exist under a folder. The path needs to distinguish them. Folder object has no such issue.

William

abc123

The client should not construct the document path using a pattern like "parent_folder_path/document_name". Instead, he should use the relative path returned by server response. Strickly speaking, the path value is opaque to client and interpreted by server only.

It follows the CMIS spec and REST style.

William

ZoranV

Wei Zhou wrote:1) This is because multiple documents with the same name can co-exist under a folder. The path needs to distinguish them. Folder object has no such issue.2) The client should not construct the document path using a pattern like "parent_folder_path/document_name". Instead, he should use the relative path returned by server response. Strickly speaking, the path value is opaque to client and interpreted by server only.

1) This is strange feature. Can you point me to CMIS specification? I'm think this is bug in Documentum CMIS implementation.

2) When creating document, server response is object id. When invoking getObject or getObjectProperties, some of its properties are cmis:name and cmis:contentStreamFileName. Both properties are filled (Documentum CMIS implementation) by documentName (why not actual pathSegment?). So, when I want to creat path reference on CMIS document, I have to call NavigationService getChildren, compare returned object ids, and take pathSegment. I think it would be more natural that cmis:name, cmis:contentStreamFileName and pathSegment are equivalent (as they are at IBM and Microsoft CMIS implementations).

abc123

I think this problem is specific to Documentum. CMIS spec doesn't define the path value for a document object, actually repository specific. However, Documentum Content Server allows duplicated names for document objects under a parent folder. The server side needs to provide a path uniquenessly representing each document object.

cmis:name is mapped to object_name of the sysobject.

But I think cmis:contentStreamFileName is negoatiable. Since Documentum doesn't have a property mapping to cmis:contentStreamFileName, we simply reuse the cmis:name.

William

ZoranV

I've checked CMIS specification (2.1.5.3 Paths).

"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."

abc123

Thanks for the good catch. CMIS spec very carefully choose the word MUST, SHOULD or MAY and each vendor is sensitive at it.

So I don't think it a bug

William

Inbox.GIF