cmis:name 和 cmis:contentStreamFilename 中的斜线
Slash in cmis:name and cmis:contentStreamFilename
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.
但是，我能够在 Documentum 7.1.0000.0146 服务器中创建以下文档：
如您所见，cmis:name 和 cmis:contentStreamFilename 都包含一个斜杠。实际上，cmis:contentStreamFilename 似乎变成了 cmis:name 的样子（加上扩展名）。
这是 Documentum 的 CMIS 实施中的错误吗？
虽然此服务器正确回复了 "normal" getObjectByPath 带有 cmis:name 路径元素的请求，但有没有办法对上面屏幕截图中的对象使用 getObjectByPath？还是 getObjectByPath 不能用于这样的服务器？
我认为 Documentum 存储库中的对象名称没有太多限制。
如果您想应用业务规则来确保没有使用“/”字符创建对象名称，请查看 BOF 框架。
我相信这是 Documentum 的 CMIS 实现中的一个错误（意思是，允许 斜杠成为 cmis:name 和 [=11= 的一部分是一个错误]).我从 Apache Chemistry Jira 项目中找到了 this bug report，其中似乎修复了一个类似的错误。一些对这个问题有所启发的评论：
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.
...和...
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.
我不太了解 Documentum，所以这个错误是否会在获取对象时出现是一个掷硬币的问题。您是否考虑过使用 CMIS Workbench 到 运行 一个简单的 CMIS 查询来使用这些属性之一找到它？如果它有效，我非常有信心（虽然不是 100%）它将与 getObjectByPath.
一起使用
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.
但是，我能够在 Documentum 7.1.0000.0146 服务器中创建以下文档：
如您所见，cmis:name 和 cmis:contentStreamFilename 都包含一个斜杠。实际上，cmis:contentStreamFilename 似乎变成了 cmis:name 的样子（加上扩展名）。
这是 Documentum 的 CMIS 实施中的错误吗？
虽然此服务器正确回复了 "normal" getObjectByPath 带有 cmis:name 路径元素的请求，但有没有办法对上面屏幕截图中的对象使用 getObjectByPath？还是 getObjectByPath 不能用于这样的服务器？
我认为 Documentum 存储库中的对象名称没有太多限制。 如果您想应用业务规则来确保没有使用“/”字符创建对象名称，请查看 BOF 框架。
我相信这是 Documentum 的 CMIS 实现中的一个错误（意思是，允许 斜杠成为 cmis:name 和 [=11= 的一部分是一个错误]).我从 Apache Chemistry Jira 项目中找到了 this bug report，其中似乎修复了一个类似的错误。一些对这个问题有所启发的评论：
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.
...和...
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.
我不太了解 Documentum，所以这个错误是否会在获取对象时出现是一个掷硬币的问题。您是否考虑过使用 CMIS Workbench 到 运行 一个简单的 CMIS 查询来使用这些属性之一找到它？如果它有效，我非常有信心（虽然不是 100%）它将与 getObjectByPath.