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 does CMIS 1.1 specify Queryable:FALSE for cmis:changeToken?

rg1_

The CMIS 1.0 Specification does not specify whether the cmis:changeToken property should be Queryable. The CMIS 1.1 Specification now states cmis:changeToken is explicitly NOT Queryable. Why is this the case? I would like to return the cmis:changeToken as part of a query resultSet to avoid extraneous getObject invocations. Thoughts?

Find more posts tagged with

Accepted answers

Florent_Guillau

You'd have to ask the OASIS CMIS Technical Committee (of which I'm a member), but I'd say that it's because change token are potentially computed or retrieved differently than other properties, and thus most CMIS servers cannot efficiently return them with the rest of the data.

I'll ask the question in the OASIS TC list to check if this change from 1.0 to 1.1 is not an oversight, because some CMIS servers may want to support it nonetheless.

All comments

Florent_Guillau

I'll ask the question in the OASIS TC list to check if this change from 1.0 to 1.1 is not an oversight, because some CMIS servers may want to support it nonetheless.

rg1_

Much thanks! I hope this turns out to be an oversight. This would seem easy and useful for Nuxeo to support, for example, given the way it generates change tokens.

Florent_Guillau

FYI the OASIS TC answer is

rg1_

Yes, it would seem useful to include a query constraint such as WHERE ANY cmis