%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Data Model
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Data Model}

CMIS provides an interface for an application to access a \emph{repository}. To do so, CMIS specifies a core data model that defines the persistent information entities that are managed by the repository, and specifies a set of basic services that an application can use to access and manipulate these entities. In accordance with the CMIS objectives, this data model does not cover all the concepts that a full-function ECM repository typically supports. Specifically, transient entities (such as programming interface objects), administrative entities (such as user profiles), and extended concepts (such as compound or virtual document, work flow and business process, event and subscription) are not included.

However, when an application connects to a CMIS service endpoint, the same endpoint MAY provide access to more than one CMIS repository. (How an application obtains a CMIS service endpoint is outside the scope of CMIS. How the application connects to the endpoint is a part of the protocol that the application uses.) An application MUST use the CMIS \cmisservicelink{getRepositories} service to obtain a list of repositories that are available at that endpoint. The repository id MUST uniquely identify an available repository at this service endpoint. Both the repository name and the repository id are opaque to CMIS. Aside from the \cmisservicelink{getRepositories} service, all other CMIS services are single-repository-scoped, and require a repository id as an input parameter. In other words, except for the \cmisservicelink{getRepositories} service, multi-repository and inter-repository operations are not supported by CMIS.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Repository
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Repository}
\label{dm:repository}

The repository itself is described by the CMIS "Get Repository Information" service. The service output is fully described in section \cmisserviceref{getRepositoryInfo}.


\subsubsection{Optional Capabilities}
\label{dm:optionalcapabilities}

Commercial ECM repositories vary in their designs. Moreover, some repositories are designed for a specific application domain and may not provide certain capabilities that are not needed for their targeted domain. Thus, a repository implementation may not necessarily be able to support all CMIS capabilities. A few CMIS capabilities are therefore "optional" for a repository to be compliant. A repository's support for each of these optional capabilities is discoverable using the \cmisservicelink{getRepositoryInfo} service. The following is the list of these optional capabilities. All capabilities are "boolean" (i.e. the repository either supports the capability entirely or not at all) unless otherwise noted.

\begin{description}
\item[Navigation Capabilities] \hfill
\begin{description}
	\item[capabilityGetDescendants] \hfill \\
	Ability for an application to enumerate the descendants of a folder via the \cmisservicelink{getDescendants} service.\\
	See section \cmisserviceref{getDescendants}.

	\item[capabilityGetFolderTree] \hfill \\
	Ability for an application to retrieve the folder tree via the \cmisservicelink{getFolderTree} service.\\
	See section \cmisserviceref{getFolderTree}.

	\item[capabilityOrderBy] \hfill \\
	Indicates the ordering capabilities of the repository.\\
 	Valid values are:
	\begin{description}
		\item[none] Ordering is not supported.
		\item[common] Only common CMIS properties are supported. See section \ref{dm:services:orderby}~\nameref{dm:services:orderby} for the list of properties.
		\item[custom] Common CMIS properties and custom object-type properties are supported.
	\end{description} 
	See section \ref{dm:services:orderby}~\nameref{dm:services:orderby}.
\end{description}
 
\item[Object Capabilities] \hfill
\begin{description}
	\item[capabilityContentStreamUpdatability] \hfill \\
	Indicates the support a repository has for updating a documents content stream.\\
 	Valid values are:
	\begin{description}
		\item[none] The content stream may never be updated.
		\item[anytime] The content stream may be updated any time.
		\item[pwconly] The content stream may be updated only when checked out. Private Working Copy (PWC) is described in section \ref{dm:versioning}~\nameref{dm:versioning}.
	\end{description} 
	See section \ref{dm:contentstream}~\nameref{dm:contentstream}.
 
	\item[capabilityChanges] \hfill \\
	Indicates what level of changes (if any) the repository exposes via the \cmisservicelink{getContentChanges} service.\\
	Valid values are:
	\begin{description}
		\item[none] The repository does not support the change log feature.
		\item[objectidsonly] The change log can return only the object ids for changed objects in the repository and an indication of the type of change, not details of the actual change.
		\item[properties] The change log can return properties and the object id for the changed objects.
		\item[all] The change log can return the object ids for changed objects in the repository and more information about the actual change.
	\end{description} 
	See section \ref{dm:changelog}~\nameref{dm:changelog}.
 
	\item[capabilityRenditions] \hfill \\
	Indicates whether or not the repository exposes renditions of document or folder objects.\\
	Valid values are:
	\begin{description}
		\item[none] The repository does not expose renditions at all.
		\item[read] Renditions are provided by the repository and readable by the client.
	\end{description}
	See section \ref{dm:renditions}~\nameref{dm:renditions}.
\end{description} 

\item[Filing Capabilities] \hfill
\begin{description}
	\item[capabilityMultifiling] \hfill \\
	Ability for an application to file a document or other file-able object in more than one folder.\\
	See section \ref{dm:folderobject}~\nameref{dm:folderobject}.
 
	\item[capabilityUnfiling] \hfill \\
	Ability for an application to leave a document or other file-able object not filed in any folder.\\
	See section \ref{dm:folderobject}~\nameref{dm:folderobject}.
 
	\item[capabilityVersionSpecificFiling] \hfill \\
	Ability for an application to file individual versions (i.e., not all versions) of a document in a folder.\\
	See section \ref{dm:versioning}~\nameref{dm:versioning}.
\end{description} 

\item[Versioning Capabilities] \hfill
\begin{description}
	\item[capabilityPWCUpdatable] \hfill \\
	Ability for an application to update the  "Private Working Copy" of a checked-out document.\\
	See section \ref{dm:versioning}~\nameref{dm:versioning}.
 
	\item[capabilityPWCSearchable] \hfill \\
	Ability of the Repository to include the "Private Working Copy" of checked-out documents in query search scope; otherwise PWC's are not searchable.\\
	See section \ref{dm:versioning}~\nameref{dm:versioning}.
 
	\item[capabilityAllVersionsSearchable] \hfill \\
	Ability of the Repository to include all versions of document. If False, typically either the latest or the latest major version will be searchable.\\
	See section \ref{dm:versioning}~\nameref{dm:versioning}.
\end{description} 

\item[Query Capabilities] \hfill
\begin{description}
	\item[capabilityQuery] \hfill \\
	Indicates the types of queries that the Repository has the ability to fulfill. Query support levels are:
	\begin{description}
		\item[none] No queries of any kind can be fulfilled.
		\item[metadataonly] Only queries that filter based on object properties can be fulfilled. Specifically, the CONTAINS() predicate function is not supported.
		\item[fulltextonly] Only queries that filter based on the full-text content of documents can be fulfilled. Specifically, only the CONTAINS() predicate function can be included in the WHERE clause.
		\item[bothseparate] The repository can fulfill queries that filter EITHER on the full-text content of documents OR on their properties, but NOT if both types of filters are included in the same query.
		\item[bothcombined] The repository can fulfill queries that filter on both the full-text content of documents and their properties in the same query.
	\end{description} 
	See section \ref{dm:query}~\nameref{dm:query}.
 
	\item[capabilityJoin] \hfill \\
	Indicates the types of JOIN keywords that the Repository can fulfill in queries. Support levels are:\
	\begin{description}
		\item[none] The repository cannot fulfill any queries that include any JOIN clauses on two primary types. If the Repository supports secondary types, JOINs on secondary types SHOULD be supported, even if the support level is \texttt{none}.
		\item[inneronly] The repository can fulfill queries that include an INNER JOIN clause, but cannot fulfill queries that include other types of JOIN clauses.
		\item[innerandouter] The repository can fulfill queries that include any type of JOIN clause defined by the CMIS query grammar.
	\end{description} 
	See section \ref{dm:query}~\nameref{dm:query}.
\end{description} 

\item[Type Capabilities] \hfill
\begin{description}
	\item[capabilityCreatablePropertyTypes]
	A list of all property data types that can be used by a client to create or update an object-type definition. See sections \ref{dm:property}~\nameref{dm:property} and \ref{dm:typemutabilityconstraints}~\nameref{dm:typemutabilityconstraints}.
	\item[capabilityNewTypeSettableAttributes]  \hfill \\
	Indicates which object-type attributes can be set by a client when a new object-type is created. This capibility is a set of booleans; one for each of the following attributes:
	\begin{itemize*}
		\item id
		\item localName
		\item localNamespace
		\item displayName
		\item queryName
		\item description
		\item creatable
		\item fileable
		\item queryable
		\item fulltextIndexed
		\item includedInSupertypeQuery
		\item controllablePolicy
		\item controllableACL
	\end{itemize*}
	The repository MUST set  the object-type attributes that cannot be set by a client or are not set by a client.\\
	See section \ref{dm:typemutability}~\nameref{dm:typemutability}.
\end{description} 

\item[ACL Capabilities] \hfill
\begin{description}
	\item[capabilityACL] \hfill \\
	Indicates the level of support for ACLs by the repository.
	\begin{description}
		\item[none] The repository does not support ACL services.
		\item[discover] The repository supports discovery of ACLs (\cmisservicelink{getACL} and other services).
		\item[manage] The repository supports discovery of ACLs AND applying ACLs (\cmisservicelink{getACL} and \cmisservicelink{applyACL} services).
	\end{description} 
	See section \ref{dm:accesscontrol}~\nameref{dm:accesscontrol}.
\end{description} 

\end{description}


\subsubsection{Implementation Information}
\label{dm:implementationinformation}

The \cmisservicelink{getRepositoryInfo} service MUST also return implementation information including vendor name, product name, product version, version of CMIS that it supports, the root folder id (see section \ref{dm:folderhierarchy}~\nameref{dm:folderhierarchy}), and MAY include other implementation-specific information. The version of CMIS that the repository supports MUST be expressed as a String that matches the specification version. For this version it is the string "1.1".


\subsubsection{Repository Features}
\label{dm:repositoryfeatures}

Repositories MAY provide information about additional features that are supported by the repository but that are outside the CMIS specification. This information is returned by the \cmisservicelink{getRepositoryInfo} service.

Clients that don't understand this information SHOULD ignore it.

The repository MUST provide a unique id for each feature. This id SHOULD take the form of a URI (see \hyperref[intro:rfc3986]{[RFC3986]}). The repository MAY also provide a version label as well as a human-readable common name and description for each feature.

Furthermore, each feature MAY supply an arbitrary number of key-value pairs.  The semantics and rules for these key-value pairs are not defined by CMIS but MAY be constrained by other specifications.



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Object
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\subsection{Object}

The entities managed by CMIS are modeled as typed \emph{objects}. There are five primary base types of objects: \emph{document objects}, \emph{folder objects}, \emph{relationship objects}, \emph{policy objects}, and \emph{item objects}. 

\begin{itemize}
	\item A \emph{document object} represents a standalone information asset. Document objects are the elementary entities managed by a CMIS repository.
	\item A \emph{folder object} represents a logical container for a collection of "file-able" objects, which include \emph{folder objects}, \emph{document objects}, \emph{policy objects}, and \emph{item objects}. Folder objects are used to organize file-able objects. Whether or not an object is file-able is specified in its object-type definition.
	\item A \emph{relationship object} represents an instance of a directional relationship between two objects. The support for relationship objects is optional. The \cmisservicelink{getTypeChildren} service when asked for the base object-types MUST return the base relationship object-type if the repository supports relationships.
	\item A \emph{policy object} represents an administrative policy, which may be "applied" to one or more "controllablePolicy" objects. Whether or not an object is controllable is specified in its object-type definition. The support for policy objects is optional. The \cmisservicelink{getTypeChildren} service when asked for the base object-types MUST return the base policy object-type if the repository supports policies.
	\item An \emph{item object} represents a generic type of CMIS information asset. Item objects are not versionable and do not have content streams like documents but have properties like all other CMIS objects. The support for item objects is optional. The \cmisservicelink{getTypeChildren} service when asked for the base object-types MUST return the base item object-type if the repository supports items.
\end{itemize} 

Additional object-types MAY be defined in a repository as subtypes of these base types. CMIS services are provided for the discovery of object-types that are defined in a repository. Furthermore, object-type management services are provided to create, modify and delete object-types if that is supported by the repository.

Every CMIS object has an opaque and immutable \emph{object id}, which is assigned by the repository when the object is created. An id uniquely identifies an object within a repository regardless of the type of the object. Repositories SHOULD assign ids that are "permanent" -- that is, they remain unchanged during the lifespan of the identified objects, and they are never reused or reassigned after the objects are deleted from the repository.

Every CMIS object has a set of named, but not explicitly ordered, \emph{properties}. (However, a repository SHOULD always return object properties in a consistent order.) Within an object, each property is uniquely identified by its property definition id. The object properties are defined by the object-type.

An object must have one and only one primary object-type, which cannot be changed. An object's primary object-type may be simply called its object-type. The primary object-type of an object classifies the object and defines the properties that the object must have.

An object MAY have zero or more secondary object types applied to it. A secondary type is a named marking that may add extra properties to an object in addition to the properties defined by the object's primary type. That is, applying a secondary type to an object adds the properties defined by this type to the object. Removing a secondary type removes the properties. 
Secondary object-types can only be defined as subtypes or descendant types of the \texttt{cmis:secondary} base type.  All other base object types and their descendant types are primary object-types.

Consequently, each instance of a primary object-type corresponds to a distinct object, whereas each instance of a secondary object type does not.  Therefore, the "creatable", "fileable", "controllablePolicy", and "controllableACL" object type attributes are not applicable to a secondary object type and must be set to FALSE.

The support for secondary types is optional, and may be discovered via the \cmisservicelink{getTypeChildren} service. See section \ref{dm:secondarytypes}~\nameref{dm:secondarytypes}.

In addition, a document object MAY have a \emph{content stream}, which may be used to hold a raw digital asset such as an image or a word-processing document. A repository MUST specify, in each object-type definition, whether document objects of that type MAY, MUST, or MUST NOT have a content stream. A document MAY also have one or more \emph{renditions} associated with it. A rendition can be a thumbnail or an alternate representation of the content stream.

Objects MAY have one \emph{Access Control List} (ACL), which controls access to the object. A set of policy objects may also control access to the object. An ACL represents a list of \emph{Access Control Entries} (ACEs). An ACE in turn represents one or more permissions being granted to a principal (a user, group, role, or something similar).

The notion of localization of the objects in the data model is entirely repository specific.

CMIS objects MAY expose additional information, such as vendor-specific workflow data, beyond the attributes described above. In this respect, the data model can be extended as desired. This specification does not standardize such extensions.


\subsubsection{Property}
\label{dm:property}

A property MAY hold zero, one, or more typed data value(s). Each property MAY be single-valued or multi-valued. A single-valued property contains a single data value, whereas a multi-valued property contains an ordered list of data values of the same type. The ordering of values in a multi-valued property SHOULD be preserved by the repository. 

A property, either single-valued or multi-valued, MAY be in a "not set" state. CMIS does not support "null" property value.
If a multi-valued property is not in a "not set" state, its property value MUST be a non-empty list of individual values. Each individual value in the list MUST NOT be in a "not set" state and MUST conform to the property's property-type.

A multi-valued property is either set or not set in its entirety. An individual value of a multi-valued property MUST NOT be in an individual "value not set" state and hold a position in the list of values. An empty list of values MUST NOT be allowed.

Every property is typed. The property-type defines the data type of the data value(s) held by the property. CMIS specifies the following property-types. They include the following data types defined by "XML Schema Part 2: Datatypes Second Edition" (see \hyperref[intro:xmlschema]{[XMLSchema]}):

\begin{description}
	\item[string] (xsd:string) 
	\item[boolean](xsd:boolean) 
	\item[decimal] (xsd:decimal)\\(see section \ref{dm:decimalpropertydefinition}~\nameref{dm:decimalpropertydefinition} for attributes specific to Decimal object-type property definitions.) 
	\item[integer] (xsd:integer)\\(see section \ref{dm:integerpropertydefinition}~\nameref{dm:integerpropertydefinition} for attributes specific to Integer object-type property definitions.) 
	\item[datetime] (xsd:dateTime)\\(see section \ref{dm:datetimepropertydefinition}~\nameref{dm:datetimepropertydefinition} for attributes specific to DateTime object-type property definitions.) 
	\item[uri] (xsd:anyURI)
\end{description}
\vspace{0.2in}

\noindent
In addition, the following property-types are also specified by CMIS:
\begin{description}
	\item[id]
	\item[html]
\end{description}
Individual protocol bindings MAY override or re-specify these property-types. 
\hfill \\

For single valued String, Id and HTML properties, a repository MAY support the distinction between a set value with an empty string (length = 0), and a "not set" value. In this case an empty value element (e.g. \texttt{<cmis:value/>}) inside of a property element will indicate a "set but empty" string property. A property element without a \texttt{<cmis:value/>} will indicate a property in a "not set" state. For repositories that do not support this distinction the latter example (absence of the  \texttt{<cmis:value>} element) should be used for all cases.


\paragraph{Id Property}
\label{dm:idproperty}

An id property holds a system-generated, read-only identifier, such as an object id, an object-type id, etc. (The id property-type is NOT defined by xsd:id.) The lexical representation of an id is an opaque string. As such, an id cannot be assumed to be interpretable syntactically or assumed to be collate-able with other ids, and can only be used in its entirety as a single atomic value. When used in a query predicate, an id can only participate in an "equal" or a "not equal" comparison with a string literal or with another id. 

While all CMIS identities share the same property-type, they do not necessarily share the same address space. Unless explicitly specified, id properties NEED NOT maintain a referential integrity constraint. Therefore, storing the id of one object in another object NEED NOT constrain the behavior of either object. A repository MAY, however, support referential constraint underneath CMIS if the effect on CMIS services remains consistent with an allowable behavior of the CMIS model. For example, a repository MAY return a \cmisexceptionlink{constraint} exception when a CMIS service call violates an underlying referential constraint maintained by the repository. In that case, an error message SHOULD be returned to the application to describe the cause of the exception and suggest a remedial action. The content of such messages is outside the scope of CMIS.


\paragraph{HTML Property}

An HTML property holds a document or fragment of Hypertext Markup Language (HTML) content. HTML properties are not guaranteed to be validated in any way. The validation behavior is entirely repository specific.


\paragraph{Query Names}
\label{dm:querynamelimitations}

All properties MUST supply a string \texttt{queryName} attribute which is used for query and filter operations on object-types. This is an opaque string with limitations. This string SHOULD NOT contain any characters that negatively interact with the BNF grammar.\\
The string MUST NOT contain:
\begin{itemize*}
	\item whitespace " "
	\item comma ","
	\item double quotes '"'
	\item single quotes "'"
	\item backslash "\textbackslash"
	\item the period "."
	\item the open "(" or close ")" parenthesis characters
\end{itemize*}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Object Type
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\subsection{Object-Type}
\label{dm:objecttypes}

An object-type defines a fixed and non-hierarchical set of properties ("schema") that all objects of that type have. This schema is used by a repository to validate objects and enforce constraints, and is also used by a user to compose object-type-based (structured) queries. 

All CMIS objects are strongly typed.  If a property not specified in an object's object-type definition is supplied by an application, an exception SHOULD be thrown.

Each object-type is uniquely identified within a repository by a system-assigned and immutable \emph{object-type identifier}, which is of type \hyperref[dm:idproperty]{Id}.

\begin{sloppypar}
A CMIS repository MUST expose exactly one collection of object-types via the "repository" services (\cmisservicelink{getTypeChildren}, \cmisservicelink{getTypeDescendants}, \cmisservicelink{getTypeDefinition}).
\end{sloppypar}

While a repository MAY define additional object-types beyond the CMIS base object-types, these object-types MUST NOT extend or alter the behavior or semantics of a CMIS service (for example, by adding new services). A repository MAY attach additional constraints to an object-type underneath CMIS, provided that the effect visible through the CMIS interface is consistent with the allowable behavior of CMIS.


\subsubsection{Object-Type Hierarchy and Inheritance}

\emph{Hierarchy} and \emph{Inheritance} for object-types are supported by CMIS in the following manner:

\begin{itemize}
	\item A CMIS repository MUST have these base types: 
	\begin{itemize}
		\item \texttt{cmis:document} object-type
		\item \texttt{cmis:folder} object-type
	\end{itemize}
	\item A CMIS repository MAY have these base types:
	\begin{itemize}
		\item \texttt{cmis:relationship} object-type
		\item \texttt{cmis:policy} object-type
		\item \texttt{cmis:item} object-type
		\item \texttt{cmis:secondary} object-type
	\end{itemize}
	\item Additional base types MUST NOT exist. Additional object-types MAY be defined as sub-types or descendant types of these six base types. 
	\item A \emph{base type} does not have a parent type.
	\item A non-base type has one and only one parent type. An object-type's \emph{parent type} is a part of the object-type definition.
	\item An object-type definition includes a set of object-type attribute values (e.g. fileable, queryable, etc.) and a property schema that will apply to objects of that type.
	\begin{itemize}
		\item There is no inheritance of object-type attributes from a parent object-type to its sub-types.
	\end{itemize}
	\item The properties of a CMIS base type MUST be inherited by its descendant types.
	\item A \emph{child type} whose immediate parent is NOT its base type SHOULD inherit all the property definitions that are specified for its parent type. In addition, it MAY have its own property definitions.
	\begin{itemize}
		\item If a property is NOT inherited by a subtype, the exhibited behavior for query MUST be as if the value of this property is "not set" for all objects of this sub-type.
	\end{itemize}
	\item The scope of a query on a given object-type is automatically expanded to include all the \emph{descendant types} of the given object-type with the attribute \texttt{includedInSuperTypeQuery} equals TRUE. This was added for synthetic types as well as to support different type hierarchies that are not necessarily the same as CMIS.  Only the properties of the given object-type, including inherited ones, MUST be used in the query. Properties defined for its descendant types MAY NOT be used in the query, and CAN NOT be returned by the query.
	\begin{itemize}
		\item If a property of its parent type is not inherited by this type, the property MUST still appear as a column in the corresponding virtual table in the relational view, but this column MUST contain a "not set" value for all objects of this type. (See section \ref{dm:query}~\nameref{dm:query}) 
	\end{itemize}
\end{itemize}


\subsubsection{Object-Type Attributes}

\paragraph{Attributes common to ALL Object-Type Definitions}
\label{dm:commontypeattributes}

All \emph{object-type definitions} MUST contain the following \emph{attributes}. Optional attributes MUST be defined but MAY have "not set" values.

\begin{cmisattribute}{id}{Id}
This opaque attribute identifies this object-type in the repository.
\end{cmisattribute}

\begin{cmisattribute}{localName}{String}
This attribute represents the underlying repository's name for the object-type.  This field is opaque and has no uniqueness constraint imposed by this specification.
\end{cmisattribute}

\begin{cmisattribute}{localNamespace}{String (optional)}
This attribute allows repositories to represent the internal namespace of the underlying repository's name for the object-type.
\end{cmisattribute}

\begin{cmisattribute}{queryName}{String (optional)}
Used for query and filter operations on object-types. This is an opaque string with limitations. See \ref{dm:querynamelimitations}~\nameref{dm:querynamelimitations} for details.
\end{cmisattribute}

\begin{cmisattribute}{displayName}{String (optional)}
Used for presentation by application.
\end{cmisattribute}

\begin{cmisattribute}{baseId}{Enum}
A value that indicates whether the base type for this object-type is the document, folder, relationship, policy, item, or secondary base type.
\end{cmisattribute}

\begin{cmisattribute}{parentId}{Id}
The id of the object-type's immediate parent type.  
It MUST be "not set" for a base type. Depending on the binding this means it might not exist on the base type object-type definition.
\end{cmisattribute}

\begin{cmisattribute}{description}{String (optional)}
Description of this object-type, such as the nature of content, or its intended use. Used for presentation by application.
\end{cmisattribute}

\begin{cmisattribute}{creatable}{Boolean}
Indicates whether new objects of this type MAY be created. If the value of this attribute is FALSE, the repository MAY contain objects of this type already, but MUST NOT allow new objects of this type to be created. 
\end{cmisattribute}

\begin{cmisattribute}{fileable}{Boolean}
Indicates whether or not objects of this type are file-able.
\end{cmisattribute}

\begin{cmisattribute}{queryable}{Boolean}
Indicates whether or not this object-type can appear in the FROM clause of a query statement. A non-queryable object-type is not visible through the relational view that is used for query, and CAN NOT appear in the FROM clause of a query statement.
\end{cmisattribute}

\begin{cmisattribute}{controllablePolicy}{Boolean}
Indicates whether or not objects of this type are controllable via policies. Policy objects can only be applied to controllablePolicy objects.
\end{cmisattribute}

\begin{cmisattribute}{controllableACL}{Boolean}
This attribute indicates whether or not objects of this type are controllable by ACL's. Only objects that are controllableACL can have an ACL.\end{cmisattribute}

\begin{cmisattribute}{fulltextIndexed}{Boolean}
Indicates whether objects of this type are indexed for full-text search for querying via the CONTAINS() query predicate. If the value of this attribute is TRUE, the full-text index MUST cover the content and MAY cover the metadata.
\end{cmisattribute}

\begin{cmisattribute}{includedInSupertypeQuery}{Boolean}
Indicates whether this type and its subtypes appear in a query of this type's ancestor types.  
For example: if \texttt{Invoice} is a sub-type of \texttt{cmis:document}, if this is TRUE on \texttt{Invoice} then for a query on \texttt{cmis:document}, instances of \texttt{Invoice} will be returned if they match. 
If this attribute is FALSE, no instances of \texttt{Invoice} will be returned even if they match the query.
\end{cmisattribute}

\begin{cmisattribute}{typeMutability.create}{Boolean (optional)}
Indicates whether new child types may be created with this type as the parent. 
\end{cmisattribute}

\begin{cmisattribute}{typeMutability.update}{Boolean (optional)}
Indicates whether clients may make changes to this type per the constraints defined in this specification.  
\end{cmisattribute}

\begin{cmisattribute}{typeMutability.delete}{Boolean (optional)}
Indicates whether clients may delete this type if there are no instances of it in the repository.
\end{cmisattribute}


\subsubsection{Object-Type Property Definitions}

Besides these object-type attributes, an object-type definition SHOULD contain inherited property definitions and zero or more additional property definitions.  All the properties of an object, including inherited properties, MUST be retrievable through the "get" services, and MAY appear in the SELECT clause of a query. 


\paragraph{Property Types}

Property types are defined in section \ref{dm:property}~\nameref{dm:property}.


\paragraph{Attributes common to ALL Object-Type Property Definitions}

All \emph{object-type property definitions} MUST contain the following \emph{attributes}. Optional attributes MUST be defined but MAY have "not set" values.

\begin{cmisattribute}{id}{Id}
This opaque attribute uniquely identifies the property in the repository. If two object-types each contain property definitions with the same id, the basic property definitions (property type, query name, cardinality) MUST be the same. Other attributes MAY be different for each type.
\end{cmisattribute}

\begin{cmisattribute}{localName}{String (optional)}
This attribute represents the underlying repository's name for the property.  This field is opaque and has no uniqueness constraint imposed by this specification.
\end{cmisattribute}

\begin{cmisattribute}{localNamespace}{String (optional)}
This attribute allows repositories to represent the internal namespace of the underlying repository's name for the property.
\end{cmisattribute}

\begin{cmisattribute}{queryName}{String (optional)}
Used for query operations on properties. This is an opaque string with limitations. See \ref{dm:querynamelimitations}~\nameref{dm:querynamelimitations} for details.
\end{cmisattribute}

\begin{cmisattribute}{displayName}{String (optional)}
Used for presentation by application.
\end{cmisattribute}

\begin{cmisattribute}{description}{String (optional)}
This is an optional attribute containing a description of the property.
\end{cmisattribute}

\begin{cmisattribute}{propertyType}{Enum}
This attribute indicates the type of this property. It MUST be one of the allowed property types. (See section \ref{dm:property}~\nameref{dm:property}.)
\end{cmisattribute}

\begin{cmisattribute}{cardinality}{Enum}
Indicates whether the property can have "zero or one" or "zero or more" values.\newline
Values:
\begin{description}
	\item[single] Property can have zero or one values (if property is not required), or exactly one value (if property is required).
	\item[multi] Property can have zero or more values (if property is not required), or one or more values (if property is required).
\end{description}
Repositories SHOULD preserve the ordering of values in a multi-valued property. That is, the order in which the values of a multi-valued property are returned in "get" services operations SHOULD be the same as the order in which they were supplied during previous create/update operation.
\end{cmisattribute}

\begin{cmisattribute}{updatability}{Enum}
Indicates under what circumstances the value of this property MAY be updated.\newline
Values:
\begin{description}
	\item[readonly] The value of this property MUST NOT ever be set directly by an application. It is a system property that is either maintained or computed by the repository. The value of a read-only property MAY be indirectly modified by other repository interactions (for example, calling \cmisservicelink{updateProperties} on an object will change the object's last modified date, even though that property cannot be directly set via an \cmisservicelink{updateProperties} service call.)
	\item[readwrite] The property value can be modified using the \cmisservicelink{updateProperties} service. 
	\item[whencheckedout] The property value MUST only be update-able using a "private working copy" document. That is, the update is either made on a "private working copy" object or made using the \cmisservicelink{checkIn} service.
	\item[oncreate] The property value MUST only be update-able during the create operation on that object.
\end{description}
\end{cmisattribute}

\begin{cmisattribute}{inherited}{Boolean}
Indicates whether the property definition is inherited from the parent type when TRUE or it is explicitly defined for this object-type when FALSE.
\end{cmisattribute}

\begin{cmisattribute}{required}{Boolean}
This attribute is only applicable to non-system properties, i.e.\ properties whose value is provided by the application. 

If TRUE, then the value of this property MUST never be set to the "not set" state when an object of this type is created/updated.  If not provided during a create or update operation, the repository MUST provide a value for this property.
If a value is not provided, then the default value defined for the property MUST be set. If no default value is provided and no default value is defined, the repository MUST throw a \cmisexceptionlink{constraint} exception.

This attribute is not applicable when the "updatability" attribute is "readonly". In that case, "required" SHOULD be set to FALSE. 

Note: For CMIS-defined object-types, the value of a system property (such as \texttt{cmis:objectId}, \texttt{cmis:createdBy}) MUST be set by the repository. However, the property's "required" attribute SHOULD be FALSE because it is read-only to applications.
\end{cmisattribute}

\begin{cmisattribute}{queryable}{Boolean}
Indicates whether or not the property MAY appear in the WHERE clause of a CMIS query statement. 

This attribute MUST have a value of FALSE if the object-type's attribute for "queryable" is set to FALSE.
\end{cmisattribute}

\begin{cmisattribute}{orderable}{Boolean}
Indicates whether the property can appear in the ORDER BY clause of a CMIS query statement or an \texttt{orderBy} parameter of \cmisservicelink{getChildren} or \cmisservicelink{getCheckedOutDocs}. 

This property MUST be FALSE for any property whose cardinality is "multi".
\end{cmisattribute}

\begin{cmisattribute}{choices}{<PropertyChoiceType list> (multi-valued, optional)}
Indicates an explicit ordered set of single values allowed for this property.

If the cardinatity of the property definition is "single" and the "openChoice" attribute is FALSE, then the property value MUST be at most one of the values listed in this attribute. 

If the cardinatity of the property definition is "single" and the "openChoice" attribute is TRUE, then the property value MAY be one of the values listed in this attribute.

If the cardinatity of the property definition is "multi" and the "openChoice" attribute is FALSE, then the property value MUST be zero, one or more than one of the values listed in this attribute. 

If the cardinatity of the property definition is "multi" and the "openChoice" attribute is TRUE, then the property value MAY be zero, one, or more than one of the values listed in this attribute.

If this attribute is "not set", then any valid value for this property based on its type may be used. 

Each choice includes a displayName and a value.  The displayName is used for presentation purpose.  The value will be stored in the property when selected.  

Choices MAY be hierarchically presented. For example: a value of "choices" for a geographic location would be represented as follows:
\begin{itemize*}
	\item Europe:
	\begin{itemize*}
		\item England
		\item France
		\item Germany
	\end{itemize*}
	\item North America
	\begin{itemize*}
		\item Canada
		\item USA
		\item Mexico
	\end{itemize*}
\end{itemize*}
\end{cmisattribute}

\begin{cmisattribute}{openChoice}{Boolean (optional if \texttt{choices} is not set)}
This attribute is only applicable to properties that provide a value for the "Choices" attribute. 

If FALSE, then the data value for the property MUST only be one of the values specified in the "Choices" attribute. If TRUE, then values other than those included in the "Choices" attribute may be set for the property.
\end{cmisattribute}

\begin{cmisattribute}{defaultValue}{<PropertyType> (optional)}
The value that the repository MUST set for the property if a value is not provided by an application when the object is created. 

If no default value is specified and an application creates an object of this type without setting a value for the property, the repository MUST attempt to store a "not set" property value.  If this occurs for a property that is defined to be required, then the creation attempt MUST throw an exception.

The attributes on the default value element are the same as the attributes on the property definition. 
\end{cmisattribute}


\paragraph{Attributes specific to Integer Object-Type Property Definitions}
\label{dm:integerpropertydefinition}

The following object attributes MUST only apply to property type definitions whose propertyType is "Integer", in addition to the common attributes specified above.  A repository MAY provide additional guidance on what values can be accepted.  If the following attributes are not present the repository behavior is undefined and it MAY throw an exception if a runtime constraint is encountered.

\begin{cmisattribute}{minValue}{Integer}
The minimum value allowed for this property.

If an application tries to set the value of this property to a value lower than minValue, the repository MUST throw a \cmisexceptionlink{constraint} exception.
\end{cmisattribute}

\begin{cmisattribute}{maxValue}{Integer}
The maximum value allowed for this property.

If an application tries to set the value of this property to a value higher than maxValue, the repository MUST throw a \cmisexceptionlink{constraint} exception.
\end{cmisattribute}


\paragraph{Attributes specific to DateTime Object-Type Property Definitions}
\label{dm:datetimepropertydefinition}

The following object attributes MUST only apply to property type definitions whose propertyType is "DateTime", in addition to the common attributes specified above.  A repository MAY provide additional guidance on what values can be accepted.  If the following attributes are not present the repository behavior is undefined and it MAY throw an exception if a runtime constraint is encountered.

\begin{cmisattribute}{resolution}{Enum}
This is the resolution supported for values of this property. Valid values for this attribute are:
\begin{description}
	\item[year] Year resolution is persisted. Date and time portion of the value should be ignored.
	\item[date] Date resolution is persisted. Time portion of the value should be ignored.
	\item[time] Time resolution is persisted.
\end{description}
\end{cmisattribute}


\paragraph{Attributes specific to Decmial Object-Type Property Definitions}
\label{dm:decimalpropertydefinition}

The following object attributes MUST only apply to property type definitions whose propertyType is "Decimal", in addition to the common attributes specified above.  A repository MAY provide additional guidance on what values can be accepted.  If the following attributes are not present the repository behavior is undefined and it MAY throw an exception if a runtime constraint is encountered.

\begin{cmisattribute}{precision}{Enum}
This is the precision in bits supported for values of this property. Valid values for this attribute are:
\begin{description}
	\item[32] 32-bit precision ("single" as specified in IEEE-754-1985).
	\item[64] 64-bit precision ("double" as specified in IEEE-754-1985).
\end{description}
\end{cmisattribute}

\begin{cmisattribute}{minValue}{Decimal}
The minimum value allowed for this property.

If an application tries to set the value of this property to a value lower than minValue, the repository MUST throw a \cmisexceptionlink{constraint} exception.
\end{cmisattribute}

\begin{cmisattribute}{maxValue}{Decimal}
The maximum value allowed for this property.

If an application tries to set the value of this property to a value higher than maxValue, the repository MUST throw a \cmisexceptionlink{constraint} exception.
\end{cmisattribute}


\paragraph{Attributes specific to String Object-Type Property Definitions}
\label{dm:stringpropertydefinition}

The following object attributes MUST only apply to property type definitions whose propertyType is "String", in addition to the common attributes specified above. A repository MAY provide additional guidance on what values can be accepted.  If the following attributes are not present the repository behavior is undefined and it MAY throw an exception if a runtime constraint is encountered.

\begin{cmisattribute}{maxLength}{Integer}
The maximum length (in characters) allowed for a value of this property.

If an application attempts to set the value of this property to a string longer than the specified maximum length, the repository MUST throw a \cmisexceptionlink{constraint} exception.  
\end{cmisattribute}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Document Object
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\subsection{Document Object}
\label{dm:documetobject}

Document objects are the elementary information entities managed by the repository.

Depending on its object-type definition, a document object may be:
\begin{description}
	\item[Version-able] Can be acted upon via the Versioning Services (for example: \cmisservicelink{checkOut}, \cmisservicelink{checkIn}). 
	\item[File-able] Can be filed in zero, one, or more than one folder via the Multi-filing Services. 
	\item[Query-able] Can be located via the Discovery Services (for example: \cmisservicelink{query}).
	\item[Controllable-Policy] Can have policies applied to it. (See section \ref{dm:policyobject}~\nameref{dm:policyobject}.)
	\item[Controllable-ACL] Can have an ACL applied to it. (See section \ref{dm:accesscontrol}~\nameref{dm:accesscontrol}.)
\end{description}

Additionally, whether a document object MUST, MAY or MUST NOT have a content stream is specified in its object-type definition. A document object MAY be associated with zero or more renditions.

Note: When a document is versioned, each version of the document is a separate document object. Thus, for document objects, an object id actually identifies a specific version of a document. 


\subsubsection{Content Stream}
\label{dm:contentstream}

A content stream is a binary stream. Its maximum length is repository specific.  Each content stream has a MIME Media Type, as defined by \hyperref[intro:rfc2045]{[RFC2045]} and \hyperref[intro:rfc2046]{[RFC2046]}.  A content stream's attributes are represented as properties of the content stream's containing document object. There is no MIME type specific attribute or name directly associated with the content stream outside of the document object. 

CMIS provides basic CRUD\footnote{Create, Read, Update and Delete} services for content stream, using the id of a content stream's containing document object for identification. A content stream also has a \texttt{contentStreamId} which is used for access to the stream. The \cmisservicelink{setContentStream} service either creates a new content stream for a document object or replaces an existing content stream. The \cmisservicelink{appendContentStream} service either creates a new content stream or appends content to an existing content stream. The \cmisservicelink{getContentStream} service retrieves a content stream. The \cmisservicelink{deleteContentStream} service deletes a content stream from a document object. In addition, the \cmisservicelink{createDocument} and \cmisservicelink{checkIn} services MAY also take a content stream as an optional input. A content stream MUST be specified if required by the object-type definition. These are the only services that operate on content stream. The \cmisservicelink{getObject} and \cmisservicelink{query} services, for example, do not return a content stream. 

\cmisservicelink{setContentStream}, \cmisservicelink{appendContentStream} and \cmisservicelink{deleteContentStream} services are considered modifications to a content stream's containing document object, and SHOULD therefore change the object's last modification date property upon successful completion.

The ability to set or delete a content stream is controlled by the \texttt{capabilityContentStreamUpdatability} capability.  


\subsubsection{Renditions}
\label{dm:renditions}

Some ECM repositories provide a facility to retrieve alternative representations of a document. These alternative representations are known as renditions. This could apply to a preview case which would enable the client to preview the content of a document without needing to download the full content. Previews are generally reduced fidelity representations such as thumbnails. Renditions can take on any general form, such as a PDF version of a word processing document.

A CMIS repository MAY expose zero or more renditions for a document or folder in addition to a document's content stream. CMIS provides no capability to create or update renditions accessed through the rendition services. Renditions are specific to the version of the document or folder and may differ between document versions. Each rendition consists of a set of rendition attributes and a rendition stream. Rendition attributes are not object properties, and are not queryable. They can be retrieved using the \cmisservicelink{getRenditions} service. A rendition stream can be retrieved using the \cmisservicelink{getContentStream} service with the rendition's streamId parameter.


\paragraph{Rendition Attributes}

A rendition has the following attributes:

\begin{cmisattribute}{streamId}{Id}
Identifies the rendition stream. 
\end{cmisattribute}

\begin{cmisattribute}{mimeType}{String}
The MIME type of the rendition stream.
\end{cmisattribute}

\begin{cmisattribute}{length}{Integer}
The length of the rendition stream in bytes.
\end{cmisattribute}

\begin{cmisattribute}{title}{String (optional)}
Human readable information about the rendition.
\end{cmisattribute}

\begin{cmisattribute}{kind}{String}
A categorization String associated with the rendition. See section \ref{dm:renditionkind}~\nameref{dm:renditionkind}.
\end{cmisattribute}

\begin{cmisattribute}{height}{Integer (optional)}
Typically used for 'image' renditions (expressed as pixels).\newline
SHOULD be present if kind = \texttt{cmis:thumbnail}.
\end{cmisattribute}

\begin{cmisattribute}{width}{Integer (optional)}
Typically used for 'image' renditions (expressed as pixels).\newline
SHOULD be present if kind = \texttt{cmis:thumbnail}.
\end{cmisattribute}

\begin{cmisattribute}{renditionDocumentId}{Id (optional)}
If specified, then the rendition can also be accessed as a document object in the CMIS services. If not set, then the rendition can only be accessed via the rendition services. Referential integrity of this id is repository specific.
\end{cmisattribute}


\paragraph{Rendition Kind}
\label{dm:renditionkind}

A rendition may be categorized via its kind. The repository is responsible for assigning kinds to renditions, including custom kinds.  A rendition kind does not necessarily identify a single rendition for a given object.

CMIS defines the following kind:
\begin{description}
	\item[cmis:thumbnail] A rendition whose purpose is to provide an image preview of the document without requiring the client to download the full document content stream. Thumbnails are generally reduced fidelity representations.
\end{description}


\subsubsection{Document Object-Type Definition}

This section describes the definition of the document object-type's attribute values and property definitions which must be present on document instance objects. All attributes and property definitions are listed by their id.  


\paragraph{Attributes specific to Document Object-Types}

The following object attributes MUST only apply to object-type definitions whose baseId is the \texttt{cmis:document} object-type, in addition to the common attributes specified above:

\begin{cmisattribute}{versionable}{Boolean}
Indicates whether or not objects of this type are version-able. (See section \ref{dm:versioning}~\nameref{dm:versioning}.)
If this attribute is set to TRUE, then documents of this type MUST be versionable. If this attribute is set to FALSE, then documents of this type MUST NOT be versionable.
\end{cmisattribute}

\begin{cmisattribute}{contentStreamAllowed}{Enum}
A value that indicates whether a content stream MAY, MUST, or MUST NOT be included in objects of this type.\newline
Values:
\begin{description}
	\item[notallowed] A content stream MUST NOT be included.
	\item[allowed] A content stream MAY be included.
	\item[required] A content stream MUST be included (i.e.\ MUST be included when the object is created, and MUST NOT be deleted).
\end{description}
\end{cmisattribute}


\paragraph{Attribute Values}

The document object-type MUST have the following attribute values.

Notes:
\begin{itemize}
	\item A value of <repository-specific> indicates that the value of the property MAY be set to any valid value for the attribute type.
	\item Unless explicitly stated otherwise, all values specified in the list MUST be followed for the object-type definition.
\end{itemize}

\cmisattributevalue{id}{cmis:document}

\cmisattributevalue{localName}{<repository-specific>}

\cmisattributevalue{localNamespace}{<repository-specific>}

\cmisattributevalue{queryName}{cmis:document}

\cmisattributevalue{displayName}{<repository-specific>}

\cmisattributevalue{baseId}{cmis:document}

\cmisattributevalue{parentId}{MUST NOT be set}

\cmisattributevalue{description}{<repository-specific>}

\cmisattributevalue{creatable}{<repository-specific>}

\cmisattributevalue{fileable}{SHOULD be TRUE}

\cmisattributevalue{queryable}{SHOULD be TRUE}

\cmisattributevalue{controllablePolicy}{<repository-specific>}

\cmisattributevalue{controllableACL}{<repository-specific>}

\cmisattributevalue{includedInSupertypeQuery}{<repository-specific>}

\cmisattributevalue{fulltextIndexed}{<repository-specific>}

\cmisattributevalue{typeMutability.create}{<repository-specific>}

\cmisattributevalue{typeMutability.update}{<repository-specific>}

\cmisattributevalue{typeMutability.delete}{<repository-specific>}

\cmisattributevalue{versionable}{<repository-specific>}

\cmisattributevalue{contentStreamAllowed}{<repository-specific>}


\paragraph{Property Definitions}

The document base object-type MUST have the following property definitions, and MAY include additional property definitions. Any attributes not specified for the property definition are repository specific. For all property definitions on base types, the query name MUST be the same as the property id. The repository MUST have the following property definitions on the document object-type:\\

\begin{cmisproperty}{cmis:name}{Name of the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{TRUE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{SHOULD be readwrite or whencheckedout}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{SHOULD be TRUE}
\end{cmisproperty}

\begin{cmisproperty}{cmis:description}{Description of the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{SHOULD be readwrite or whencheckedout}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{If the repository doesn't support object descriptions, the Updatability SHOULD be readonly and the repository SHOULD return a "not set" value for this property.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:objectId}{Id of the object.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:baseTypeId}{Id of the base object-type for the object.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:objectTypeId}{Id of the object's type.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:secondaryObjectTypeIds}{Ids of the object's secondary types.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{multi}
	\cmispropertydetail{Updatability}{readwrite if secondary types are supported,\newline readonly otherwise}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{FALSE}
	\cmispropertycomment{If the repository does not support secondary types, the repository MUST return "not set".}
\end{cmisproperty}

\begin{cmisproperty}{cmis:createdBy}{User who created the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:creationDate}{DateTime when the object was created.}
	\cmispropertydetail{Property Type}{DateTime}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:lastModifiedBy}{User who last modified the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:lastModificationDate}{DateTime when the object was last modified.}
	\cmispropertydetail{Property Type}{DateTime}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:changeToken}{Opaque token used for optimistic locking and concurrency checking. (See section \ref{dm:changetokens}~\nameref{dm:changetokens}.)}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{FALSE}
	\cmispropertydetail{Orderable}{FALSE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it. If the repository does not support change tokens, this property SHOULD not be set.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:isImmutable}{Defines if the object can be modified. If TRUE the repository MUST throw an error at any attempt to update or delete the object.}
	\cmispropertydetail{Property Type}{Boolean}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:isLatestVersion}{See section \ref{dm:versioning}~\nameref{dm:versioning}.}
	\cmispropertydetail{Property Type}{Boolean}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it. Version property values are repository-specific when a document is defined as non-versionable.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:isMajorVersion}{See section \ref{dm:versioning}~\nameref{dm:versioning}.}
	\cmispropertydetail{Property Type}{Boolean}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it. Version property values are repository-specific when a document is defined as non-versionable.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:isLatestMajorVersion}{See section \ref{dm:versioning}~\nameref{dm:versioning}.}
	\cmispropertydetail{Property Type}{Boolean}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it. Version property values are repository-specific when a document is defined as non-versionable.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:isPrivateWorkingCopy}{See section \ref{dm:versioning}~\nameref{dm:versioning}.}
	\cmispropertydetail{Property Type}{Boolean}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it. Version property values are repository-specific when a document is defined as non-versionable.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:versionLabel}{See section \ref{dm:versioning}~\nameref{dm:versioning}.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it. Version property values are repository-specific when a document is defined as non-versionable.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:versionSeriesId}{See section \ref{dm:versioning}~\nameref{dm:versioning}.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it. Version property values are repository-specific when a document is defined as non-versionable.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:isVersionSeriesCheckedOut}{See section \ref{dm:versioning}~\nameref{dm:versioning}.}
	\cmispropertydetail{Property Type}{Boolean}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it. Version property values are repository-specific when a document is defined as non-versionable.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:versionSeriesCheckedOutBy}{See section \ref{dm:versioning}~\nameref{dm:versioning}.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository SHOULD return this property with a non-empty value if the document is checked out and the property filter does not exclude it. The repository MUST return "not set" if the document is not checked out. Version property values are repository-specific when a document is defined as non-versionable.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:versionSeriesCheckedOutId}{See section \ref{dm:versioning}~\nameref{dm:versioning}.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository SHOULD return this property with a non-empty value if the document is checked out, the PWC is visible to the current user and the property filter does not exclude it. If the PWC is not visible to the current user, the repository SHOULD return "not set". The repository MUST return "not set" if the document is not checked out. Version property values are repository-specific when a document is defined as non-versionable.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:checkinComment}{See section \ref{dm:versioning}~\nameref{dm:versioning}.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{Version property values are repository-specific when a document is defined as non-versionable.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:contentStreamLength}{Length of the content stream (in bytes).\newline  See also section \ref{dm:contentstream}~\nameref{dm:contentstream}.}
	\cmispropertydetail{Property Type}{Integer}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the document has a content stream and the property filter does not exclude it. If the document has no content stream, the repository MUST return "not set".}
\end{cmisproperty}

\begin{cmisproperty}{cmis:contentStreamMimeType}{MIME type of the content stream.\newline  See also section \ref{dm:contentstream}~\nameref{dm:contentstream}.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the document has a content stream and the property filter does not exclude it. If the document has no content stream, the repository MUST return "not set".}
\end{cmisproperty}

\begin{cmisproperty}{cmis:contentStreamFileName}{File name of the content stream.\newline  See also section \ref{dm:contentstream}~\nameref{dm:contentstream}.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the document has a content stream and the property filter does not exclude it. If the document has no content stream, the repository MUST return "not set".}
\end{cmisproperty}

\begin{cmisproperty}{cmis:contentStreamId}{Id of the content stream.\newline See also section \ref{dm:contentstream}~\nameref{dm:contentstream}.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{If the document has no content stream, the repository MUST return "not set".}
\end{cmisproperty}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Folder Object
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\subsection{Folder Object}
\label{dm:folderobject}

A folder object serves as the anchor for a collection of file-able objects. The folder object has an implicit hierarchical relationship with each object in its collection, with the anchor folder object being the \emph{parent object} and each object in the collection being a \emph{child object}. This implicit relationship has specific containment semantics which MUST be maintained by the repository with implicit referential integrity. (That is, there will never be a dangling parent-relationship or a dangling child-relationship. Furthermore, object A is a parent of object B if and only if object B is a child of object A.) This system-maintained implicit relationship is distinct from an explicit relationship which is instantiated by an application-maintained relationship object. (See section \ref{dm:relationshipobject}~\nameref{dm:relationshipobject}.)

A folder object does not have a content-stream and is not version-able.  A folder object MAY be associated with zero or more renditions (see section \ref{dm:renditions}~\nameref{dm:renditions}).


\subsubsection{File-able Objects}

A \emph{file-able} object is one that MAY be "filed" into a folder. That is, it MAY be a child object of a folder object.  The following list defines whether the base CMIS object-types are file-able:

\begin{description}
	\item[cmis:folder] MUST be file-able
	\item[cmis:document] MAY be file-able
	\item[cmis:relationship] MUST NOT be file-able
	\item[cmis:policy] MAY be file-able
	\item[cmis:item] MAY be file-able
\end{description}


\paragraph{Document Version Series and Filing}

Since document objects are versionable, a document object's membership in a folder MAY be version-specific or version-independent. That is, the folder membership MAY be restricted to that particular version of the document or MAY apply to all versions of the document. Whether or not a repository supports version-specific filing is discoverable via the \cmisservicelink{getRepositoryInfo} service. 

When the child objects of a folder are retrieved, a specific version of a document MAY be returned. If the repository supports version-specific filing, the specific version filed in that folder is returned. If the repository does not support version-specific filing, the latest version or the latest major version of the document is returned. 

Likewise, this version sensitivity in child-binding also affects the behavior of parent retrieval for a document object, as well as the scope of the \texttt{IN\_FOLDER()} and \texttt{IN\_TREE()} function calls in a query. For non-versionable fileable objects, their membership in a folder does not have version sensitivity.


\paragraph{Filing Restrictions by Object-Type}
\label{dm:filingrestrictions}

A folder collection's membership MAY be restricted by object-type. Each folder object has a multi-valued \texttt{cmis:allowedChildObjectTypeIds} property, which specifies that only objects of these types are allowed to be its children. If this property is "not set", then objects of any file-able type MAY be filed in the folder.  It is repository-specific if subtypes of the types listed in the \texttt{cmis:allowedChildObjectTypeIds} property MAY be filed in the folder.

Because of these filing constraints, when a new folder object is created, an existing folder object MUST be specified as its parent. 

When a non-file-able object is created, a parent folder MUST NOT be specified. 

When a file-able object is deleted, it is removed from any folder collection in which the object is a member. In other words, when an object is deleted, all implicit parent-child relationships with the deleted object as a child cease to exist. 


\subsubsection{Folder Hierarchy}
\label{dm:folderhierarchy}

CMIS imposes the following constraints on folder objects:
\begin{itemize}
	\item Every folder object, except for one which is called the \emph{root folder}, MUST have one and only one parent folder. The root folder does not have a parent.
	\item A cycle in folder containment relationships is not allowed. That is, a folder object cannot have itself as one of its descendant objects.
	\item A child object that is a folder object can itself be the parent object of other file-able objects.
\end{itemize}

With these constraints, the folder objects in a CMIS repository necessarily form a strict hierarchy, with the \emph{root folder} being the root of the hierarchy.

The child objects of a given folder object, their child objects, and grandchild objects, etc., are called \emph{descendant objects} of the given folder object. A folder object together with all its descendant objects are collectively called a \emph{tree} rooted at that folder object.

A non-folder object does not have any descendant objects. Thus, a \emph{folder graph} that consists of all fileable objects as nodes, and all the implicit folder containment relationships as directed edges from parent to child, is a directed acyclic graph, possibly with some disconnected (orphan) nodes. It follows that the tree rooted at any given folder object is also a directed acyclic graph, although a non-folder object in the tree MAY have ancestors that are not ancestors of the rooted folder.

\cmisgraphics{folders}{width=0.6\textwidth}{Folder Graph}
%\begin{figure}[htb]
%\centering
%\includegraphics[width=0.6\textwidth]{folders.pdf}
%\caption{Folder Graph}
%\end{figure}

Folder objects are handled using the basic CRUD services for objects, and the folder graph is traversed using the navigation services.

The root folder is a special folder such that it cannot be created, deleted, or moved using CMIS services. Otherwise, it behaves like any other folder object.


\subsubsection{Paths}
\label{dm:paths}

A folder hierarchy MAY be represented in a canonical notation such as path.  For CMIS, a path is represented by:
\begin{itemize}
	\item '/' for the root folder.
	\item All paths start with the root folder.
	\item A set of the folder and object path segments separated by '/' in order of closest to the root.
	\item Folder and object path segments are specified by \texttt{pathSegment} tokens which can be retrieved by all services that take an \texttt{includePathSegments} parameter (for example \cmisservicelink{getChildren}). 
	\item A \texttt{pathSegment} token MUST not include a '/' character.\\It is repository specific how a repository chooses the value for \texttt{pathSegment}.  Repositories might choose to use \texttt{cmis:name} or content stream filename for \texttt{pathSegment} token.
	\item The \texttt{pathSegment} token for each item MUST uniquely identify the item in the folder.
\end{itemize}

That is, if folder A is under the root, and folder B is under A, then the path would be \texttt{/A/B}.

A path for an object may be calculated by taking the item's parent folder \texttt{cmis:path} property and appending the '/' character and the object's \texttt{pathSegment}.  This constructed path may be given as input to the \cmisservicelink{getObjectByPath} service for object by path retrieval.

The \cmisservicelink{getObjectParents} service returns \texttt{relativePathSegment} tokens. These tokens are the \texttt{pathSegment} of the input object relative to the parent folders.


\subsubsection{Folder Object-Type Definition}

This section describes the definition of the folder object-type's attribute values and property definitions which must be present on folder instance objects. All attributes and property definitions are listed by their id.  


\paragraph{Attribute Values}

The folder object-type MUST have the following attribute values.

Notes:
\begin{itemize}
	\item A value of <repository-specific> indicates that the value of the property MAY be set to any valid value for the attribute type.
	\item Unless explicitly stated otherwise, all values specified in the list MUST be followed for the object-type definition.
\end{itemize}

\cmisattributevalue{id}{cmis:folder}

\cmisattributevalue{localName}{<repository-specific>}

\cmisattributevalue{localNamespace}{<repository-specific>}

\cmisattributevalue{queryName}{cmis:folder}

\cmisattributevalue{displayName}{<repository-specific>}

\cmisattributevalue{baseId}{cmis:folder}

\cmisattributevalue{parentId}{MUST NOT be set}

\cmisattributevalue{description}{<repository-specific>}

\cmisattributevalue{creatable}{<repository-specific>}

\cmisattributevalue{fileable}{TRUE}

\cmisattributevalue{queryable}{SHOULD be TRUE}

\cmisattributevalue{controllablePolicy}{<repository-specific>}

\cmisattributevalue{controllableACL}{<repository-specific>}

\cmisattributevalue{includedInSupertypeQuery}{<repository-specific>}

\cmisattributevalue{fulltextIndexed}{<repository-specific>}

\cmisattributevalue{typeMutability.create}{<repository-specific>}

\cmisattributevalue{typeMutability.update}{<repository-specific>}

\cmisattributevalue{typeMutability.delete}{<repository-specific>}


\paragraph{Property Definitions}

The folder base object-type MUST have the following property definitions, and MAY include additional property definitions. Any attributes not specified for the property definition are repository specific. For all property definitions on base types, the query name MUST be the same as the property id. The repository MUST have the following property definitions on the folder object-type:\\

\begin{cmisproperty}{cmis:name}{Name of the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{TRUE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{SHOULD be readwrite}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{SHOULD be TRUE}
\end{cmisproperty}

\begin{cmisproperty}{cmis:description}{Description of the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{SHOULD be readwrite}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{If the repository doesn't support object descriptions, the Updatability SHOULD be readonly and the repository SHOULD return a "not set" value for this property.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:objectId}{Id of the object.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:baseTypeId}{Id of the base object-type for the object.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:objectTypeId}{Id of the object's type.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:secondaryObjectTypeIds}{Ids of the object's secondary types.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{multi}
	\cmispropertydetail{Updatability}{readwrite if secondary types are supported,\newline readonly otherwise}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{FALSE}
	\cmispropertycomment{If the repository does not support secondary types, the repository MUST return "not set".}
\end{cmisproperty}

\begin{cmisproperty}{cmis:createdBy}{User who created the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:creationDate}{DateTime when the object was created.}
	\cmispropertydetail{Property Type}{DateTime}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:lastModifiedBy}{User who last modified the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:lastModificationDate}{DateTime when the object was last modified.}
	\cmispropertydetail{Property Type}{DateTime}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:changeToken}{Opaque token used for optimistic locking and concurrency checking. (See section \ref{dm:changetokens}~\nameref{dm:changetokens}.)}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{FALSE}
	\cmispropertydetail{Orderable}{FALSE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it. If the repository does not support change tokens, this property SHOULD not be set.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:parentId}{Id of the parent folder of the folder.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{FALSE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:path}{The fully qualified path to this folder.\newline  See section \ref{dm:paths}~\nameref{dm:paths}. }
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:allowedChildObjectTypeIds}{Id's of the set of object-types that can be created, moved or filed into this folder.\newline  See section \ref{dm:filingrestrictions}~\nameref{dm:filingrestrictions}. }
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{multi}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{FALSE}
	\cmispropertydetail{Orderable}{FALSE}
\end{cmisproperty}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Relationship Object
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\subsection{Relationship Object}
\label{dm:relationshipobject}

A relationship object is semantically a \emph{dependent object}. A relationship object MUST NOT have a content stream, and MUST NOT be versionable, MAY be queryable, and MUST NOT be fileable, although it MAY be controllable. 

If a repository does not support relationship objects, the relationship base object-type SHOULD NOT be returned by a \cmisservicelink{getTypeChildren} service call.

A \emph{relationship object} instantiates an explicit, binary, directional, non-invasive, and typed relationship between a \emph{source object} and a \emph{target object}. The source object and the target object MUST both be independent objects, such as a document object, a folder object, a policy object, or an item object. Whether a policy object is allowed to be the source or target object of a relationship object is repository-specific.

The relationship instantiated by a relationship object is explicit since it is explicitly represented by an object and is explicitly managed by application.

This relationship is non-invasive in the sense that creating or removing this relationship SHOULD NOT modify either the source or the target object. That is, it SHOULD NOT require an update capability (or permission) on either object; SHOULD NOT affect the versioning state of either object; and SHOULD NOT change their "Last Modification Date". 

Explicit relationships can be used to create an arbitrary relationship graph among independent objects. Such a relationship graph is only structural in nature. No inheritance or transitive properties are attached to a relationship graph.

The notion of a source object and a target object of a relationship is used solely to indicate the direction of the relationship. No semantics or implementation bias is implied by this terminology. 

The binding of a relationship object to a source document object or to a target document object MAY be either version-specific or version-independent. This version sensitivity is repository-specific, and is largely transparent to CMIS. An independent object MAY participate in any number of explicit relationships, as the source object for some and as the target object for others. Multiple relationships MAY exist between the same pair of source and target objects. 

Referential integrity, either between the source object and the target object, or between the relationship object and the source or target object, is repository-specific. Therefore, creating an explicit relationship between two objects MAY impose a constraint on any of the three objects, and removing a relationship or deleting either the source or the target object MAY be restricted by such a constraint. If the source or the target object of a relationship is deleted, the repository MAY automatically delete the relationship object. 

Like all CMIS objects, relationship objects are typed. Typing relationship allows them to be grouped, identified, and traversed by type id, and for properties to be defined for individual relationship types. 

Additionally, a relationship object-type MAY specify that only objects of a specific object-type can participate as the source object or target object for relationship objects of that type. If no such constraints are specified, then an independent object of any type MAY be the source or the target of a relationship object of that type.

When a relationship object is created, the source object id and the target object id MUST reference valid non-relationship CMIS objects. 
When a relationship object is retrieved, its source object or target object MAY no longer exist, since referential integrity MAY not be maintained by a repository.

In addition to object CRUD services, a \cmisservicelink{getObjectRelationships} service may be used to return a set of relationship objects in which a given independent object is identified as the source or the target object, according to the binding semantics maintained by the repository (i.e., either a version-specific or a version-independent binding as described above). 


\subsubsection{Relationship Object-Type Definition}

This section describes the definition of the relationship object-type's attribute values and property definitions which must be present on relationship instance objects. All attributes and property definitions are listed by their id.  


\paragraph{Attributes specific to Relationship Object-Types}

The following object attributes MUST only apply to object-type definitions whose baseId is the \texttt{cmis:relationship} object-type, in addition to the common attributes specified above:

\begin{cmisattribute}{allowedSourceTypes}{Id (multi-valued)}
A list of object-type ids, indicating that the source object of a relationship object of this type MUST only be one of the types listed. 

If this attribute is "not set", then the source object MAY be of any type.
\end{cmisattribute}

\begin{cmisattribute}{allowedTargetTypes}{Id (multi-valued)}
A list of object-type ids, indicating that the target object of a relationship object of this type MUST only be one of the types listed. 

If this attribute is "not set", then the target object MAY be of any type.
\end{cmisattribute}


\paragraph{Attribute Values}

The relationship object-type MUST have the following attribute values.

Notes:
\begin{itemize}
	\item A value of <repository-specific> indicates that the value of the property MAY be set to any valid value for the attribute type.
	\item Unless explicitly stated otherwise, all values specified in the list MUST be followed for the object-type definition.
\end{itemize}

\cmisattributevalue{id}{cmis:relationship}

\cmisattributevalue{localName}{<repository-specific>}

\cmisattributevalue{localNamespace}{<repository-specific>}

\cmisattributevalue{queryName}{cmis:relationship}

\cmisattributevalue{displayName}{<repository-specific>}

\cmisattributevalue{baseId}{cmis:relationship}

\cmisattributevalue{parentId}{MUST NOT be set}

\cmisattributevalue{description}{<repository-specific>}

\cmisattributevalue{creatable}{<repository-specific>}

\cmisattributevalue{fileable}{FALSE}

\cmisattributevalue{queryable}{<repository-specific>}

\cmisattributevalue{controllablePolicy}{<repository-specific>}

\cmisattributevalue{controllableACL}{<repository-specific>}

\cmisattributevalue{includedInSupertypeQuery}{<repository-specific>}

\cmisattributevalue{fulltextIndexed}{<repository-specific>}

\cmisattributevalue{typeMutability.create}{<repository-specific>}

\cmisattributevalue{typeMutability.update}{<repository-specific>}

\cmisattributevalue{typeMutability.delete}{<repository-specific>}

\cmisattributevalue{allowedSourceTypes}{<repository-specific>}

\cmisattributevalue{allowedTargetTypes}{<repository-specific>}


\paragraph{Property Definitions}

The relationship base object-type MUST have the following property definitions, and MAY include additional property definitions. Any attributes not specified for the property definition are repository specific. For all property definitions on base types, the query name MUST be the same as the property id. The repository MUST have the following property definitions on the relationship object-type:\\

\begin{cmisproperty}{cmis:name}{Name of the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{TRUE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{SHOULD be readwrite}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{SHOULD be TRUE}
\end{cmisproperty}

\begin{cmisproperty}{cmis:description}{Description of the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{SHOULD be readwrite}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{If the repository doesn't support object descriptions, the Updatability SHOULD be readonly and the repository SHOULD return a "not set" value for this property.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:objectId}{Id of the object.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:baseTypeId}{Id of the base object-type for the object.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:objectTypeId}{Id of the object's type.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:secondaryObjectTypeIds}{Ids of the object's secondary types.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{multi}
	\cmispropertydetail{Updatability}{readwrite if secondary types are supported,\newline readonly otherwise}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{FALSE}
	\cmispropertycomment{If the repository does not support secondary types, the repository MUST return "not set".}
\end{cmisproperty}

\begin{cmisproperty}{cmis:createdBy}{User who created the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:creationDate}{DateTime when the object was created.}
	\cmispropertydetail{Property Type}{DateTime}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:lastModifiedBy}{User who last modified the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:lastModificationDate}{DateTime when the object was last modified.}
	\cmispropertydetail{Property Type}{DateTime}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:changeToken}{Opaque token used for optimistic locking and concurrency checking. (See section \ref{dm:changetokens}~\nameref{dm:changetokens}.)}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{FALSE}
	\cmispropertydetail{Orderable}{FALSE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it. If the repository does not support change tokens, this property SHOULD not be set.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:sourceId}{Id of the source object of the relationship.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:targetId}{Id of the target object of the relationship.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Policy Object
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\subsection{Policy Object}
\label{dm:policyobject}

A policy object represents an administrative policy that can be enforced by a repository. CMIS does not specify what kinds of administrative policies that are specifically supported, nor attempts to model administrative policy of any particular kind. Only a base object-type is specified for policy objects. Each policy object holds the text of an administrative policy as a repository-specific string, which is opaque to CMIS and which may be used to support policies of various kinds. A repository may create subtypes of this base type to support different kinds of administrative policies more specifically. If a repository does not support policy objects, the policy base object-type SHOULD NOT be returned by a \cmisservicelink{getTypeChildren} service call. This is an extension point for repositories that want to expose other capabilities via CMIS that are not supported directly in CMIS.

Aside from allowing an application to create and maintain policy objects, CMIS allows an application to "apply" a policy to an object, and to remove an applied policy from an object. An object to which a policy may be applied is called a controllable object. A policy MAY be applied to multiple controllable objects. Conversely, a repository MAY allow multiple policies applied to a controllable object. (A repository may, for example, impose constraints such as only one policy of each kind can be applied to an object.) Whether or not an object is controllable is specified by the object's type definition. Applying a policy to an object is to place the object under the control of that policy (while the object may also be under the control of other policies at the same time), and removing an applied policy from one of its controlled objects is to remove the corresponding control from that object. This control may change the state of the object, may impose certain constraints on service calls operating on this object, or may cause certain management actions to take place. The effect of this control, when this effect takes place, and how this control interacts with other controls, are repository-specific. Only directly/explicitly applied policies are covered by CMIS. Indirectly applying policy to an object, e.g. through inheritance, is outside the scope of CMIS.

A policy object does not have a content stream and is not versionable. It may be fileable, queryable or controllable. Policy objects are handled using the basic CRUD services for objects. If a policy is updated, the change may alter the corresponding control on objects that the policy is currently applied to. If a controlled object is deleted, all the policies applied to that object, if there are any, are removed from that object. A policy object that is currently applied to one or more controllable objects CAN NOT be deleted. That is, there is an implicit referential constraint from a controlled object to its controlling policy object(s). Besides the basic CRUD services, the \cmisservicelink{applyPolicy} and the \cmisservicelink{removePolicy} services may be used to apply a policy object to a controllable object and respectively to remove an applied policy from one of its controlled objects. In addition, the \cmisservicelink{getAppliedPolicies} service may be used to obtain the policy objects that are currently applied to a controllable object.


\subsubsection{Policy Object-Type Definition}

This section describes the definition of the policy object-type's attribute values and property definitions which must be present on policy instance objects. All attributes and property definitions are listed by their id.  


\paragraph{Attribute Values}

The policy object-type MUST have the following attribute values.

Notes:
\begin{itemize}
	\item A value of <repository-specific> indicates that the value of the property MAY be set to any valid value for the attribute type.
	\item Unless explicitly stated otherwise, all values specified in the list MUST be followed for the object-type definition.
\end{itemize}

\cmisattributevalue{id}{cmis:policy}

\cmisattributevalue{localName}{<repository-specific>}

\cmisattributevalue{localNamespace}{<repository-specific>}

\cmisattributevalue{queryName}{cmis:policy}

\cmisattributevalue{displayName}{<repository-specific>}

\cmisattributevalue{baseId}{cmis:policy}

\cmisattributevalue{parentId}{MUST NOT be set}

\cmisattributevalue{description}{<repository-specific>}

\cmisattributevalue{creatable}{<repository-specific>}

\cmisattributevalue{fileable}{<repository-specific>}

\cmisattributevalue{queryable}{<repository-specific>}

\cmisattributevalue{controllablePolicy}{<repository-specific>}

\cmisattributevalue{controllableACL}{<repository-specific>}

\cmisattributevalue{includedInSupertypeQuery}{<repository-specific>}

\cmisattributevalue{fulltextIndexed}{<repository-specific>}

\cmisattributevalue{typeMutability.create}{<repository-specific>}

\cmisattributevalue{typeMutability.update}{<repository-specific>}

\cmisattributevalue{typeMutability.delete}{<repository-specific>}


\paragraph{Property Definitions}

The policy base object-type MUST have the following property definitions, and MAY include additional property definitions. Any attributes not specified for the property definition are repository specific. For all property definitions on base types, the query name MUST be the same as the property id. The repository MUST have the following property definitions on the policy object-type:\\

\begin{cmisproperty}{cmis:name}{Name of the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{TRUE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{SHOULD be readwrite}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{SHOULD be TRUE}
\end{cmisproperty}

\begin{cmisproperty}{cmis:description}{Description of the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{SHOULD be readwrite}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{If the repository doesn't support object descriptions, the Updatability SHOULD be readonly and the repository SHOULD return a "not set" value for this property.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:objectId}{Id of the object.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:baseTypeId}{Id of the base object-type for the object.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:objectTypeId}{Id of the object's type.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:secondaryObjectTypeIds}{Ids of the object's secondary types.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{multi}
	\cmispropertydetail{Updatability}{readwrite if secondary types are supported,\newline readonly otherwise}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{FALSE}
	\cmispropertycomment{If the repository does not support secondary types, the repository MUST return "not set".}
\end{cmisproperty}

\begin{cmisproperty}{cmis:createdBy}{User who created the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:creationDate}{DateTime when the object was created.}
	\cmispropertydetail{Property Type}{DateTime}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:lastModifiedBy}{User who last modified the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:lastModificationDate}{DateTime when the object was last modified.}
	\cmispropertydetail{Property Type}{DateTime}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:changeToken}{Opaque token used for optimistic locking and concurrency checking.(See section \ref{dm:changetokens}~\nameref{dm:changetokens}.)}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{FALSE}
	\cmispropertydetail{Orderable}{FALSE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it. If the repository does not support change tokens, this property SHOULD not be set.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:policyText}{User-friendly description of the policy.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
\end{cmisproperty}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Item Object
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\subsection{Item Object}
\label{dm:itemobject}

The item object is an extension point for repositories that want to expose other object types via CMIS that do not fit the definition for document, folder, relationship or policy. For example an independently persistable collection of properties that was not versionable and did not have content. Another example could be a base identity object for users and groups.

A repository may create subtypes of this base type to support different kinds of generic base objects more specifically. If a repository does not support item objects, the item base object-type SHOULD NOT be returned by a \cmisservicelink{getTypeChildren} service call. Like the other CMIS objects (folder, policy and relationship), item objects are not versionable and do not have content. Item objects are manipulated with the basic CRUD operations as well as with \cmisservicelink{query} if the repository has them marked as queryable. 


\subsubsection{Item Object-Type Definition}

This section describes the definition of the item object-type's attribute values and property definitions which must be present on item instance objects. All attributes and property definitions are listed by their id.  


\paragraph{Attribute Values}

The item object-type MUST have the following attribute values.

Notes:
\begin{itemize}
	\item A value of <repository-specific> indicates that the value of the property MAY be set to any valid value for the attribute type.
	\item Unless explicitly stated otherwise, all values specified in the list MUST be followed for the object-type definition.
\end{itemize}

\cmisattributevalue{id}{cmis:item}

\cmisattributevalue{localName}{<repository-specific>}

\cmisattributevalue{localNamespace}{<repository-specific>}

\cmisattributevalue{queryName}{cmis:item}

\cmisattributevalue{displayName}{<repository-specific>}

\cmisattributevalue{baseId}{cmis:item}

\cmisattributevalue{parentId}{MUST NOT be set}

\cmisattributevalue{description}{<repository-specific>}

\cmisattributevalue{creatable}{<repository-specific>}

\cmisattributevalue{fileable}{<repository-specific>}

\cmisattributevalue{queryable}{<repository-specific>}

\cmisattributevalue{controllablePolicy}{<repository-specific>}

\cmisattributevalue{controllableACL}{<repository-specific>}

\cmisattributevalue{includedInSupertypeQuery}{<repository-specific>}

\cmisattributevalue{fulltextIndexed}{<repository-specific>}

\cmisattributevalue{typeMutability.create}{<repository-specific>}

\cmisattributevalue{typeMutability.update}{<repository-specific>}

\cmisattributevalue{typeMutability.delete}{<repository-specific>}


\paragraph{Property Definitions}

The item base object-type MUST have the following property definitions, and MAY include additional property definitions. Any attributes not specified for the property definition are repository specific. For all property definitions on base types, the query name MUST be the same as the property id. The repository MUST have the following property definitions on the item object-type:\\

\begin{cmisproperty}{cmis:name}{Name of the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{TRUE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{SHOULD be readwrite}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{SHOULD be TRUE}
	\cmispropertycomment{If the repository does not support names for items, it MAY ignore the value of this property when provided by a client. The repository MUST return a name even if the item has no name. It MAY return the object id in this case.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:description}{Description of the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{SHOULD be readwrite}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository specific>}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{If the repository doesn't support object descriptions, the Updatability SHOULD be readonly and the repository SHOULD return a "not set" value for this property.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:objectId}{Id of the object.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:baseTypeId}{Id of the base object-type for the object.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:objectTypeId}{Id of the object's type.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{<repository specific>}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:secondaryObjectTypeIds}{Ids of the object's secondary types.}
	\cmispropertydetail{Property Type}{Id}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{multi}
	\cmispropertydetail{Updatability}{readwrite if secondary types are supported, readonly otherwise}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{FALSE}
	\cmispropertycomment{If the repository does not support secondary types, the repository MUST return "not set".}
\end{cmisproperty}

\begin{cmisproperty}{cmis:createdBy}{User who created the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:creationDate}{DateTime when the object was created.}
	\cmispropertydetail{Property Type}{DateTime}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:lastModifiedBy}{User who last modified the object.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:lastModificationDate}{DateTime when the object was last modified.}
	\cmispropertydetail{Property Type}{DateTime}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{TRUE}
	\cmispropertydetail{Orderable}{TRUE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it.}
\end{cmisproperty}

\begin{cmisproperty}{cmis:changeToken}{Opaque token used for optimistic locking and concurrency checking.(See section \ref{dm:changetokens}~\nameref{dm:changetokens}.)}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readonly}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{FALSE}
	\cmispropertydetail{Orderable}{FALSE}
	\cmispropertycomment{The repository MUST return this property with a non-empty value if the property filter does not exclude it. If the repository does not support change tokens, this property SHOULD not be set.}
\end{cmisproperty}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Secondary Object-Types
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\subsection{Secondary Object-Types}
\label{dm:secondarytypes}

A secondary type defines a set of properties that can be dynamically added to and removed from objects. That is, an object can get and lose additional properties that are not defined by its primary type during its lifetime. Multiple secondary types can be applied to the same object at the same time.

Secondary types can be simple markers without properties. Alternatively, they can contain technical information about an object. For example, a repository might analyze the content of a document, detects a photo and adds a secondary type that adds EXIF data to the document. Applications might want to attach temporary data to an object such the state of the object in a workflow. Secondary types may also change the behaviour of the repository. 

The CMIS specification does not define the semantics of secondary types with the exception of secondary types for retentions and holds (see section \ref{dm:renditionsandholds}~\nameref{dm:renditionsandholds}). CMIS provides a way to apply and remove secondary types to/from an object. Additionally, CMIS provides an optional ability to create, update and remove secondary types.

If a repository does not support secondary types, the secondary type base object-type \texttt{cmis:secondary} SHOULD NOT be returned by a \cmisservicelink{getTypeChildren} service call.

The base object-type does not specify any property definitions and its sole purpose is to be the root type of all other secondary object-types. Repositories MAY provide property definitions on the base type that are then inherited by other secondary object-types.

Secondary types can be applied to and removed from an object at any time. An object MAY have zero or more secondary types assigned to it.
When a secondary type is applied, the object provides the properties that are defined by the secondary type. When a secondary type is removed, it loses these properties and its values.

A repository MAY not allow applying or removing certain secondary object-types to certain objects based on rules that are not determined in this specification. The repository SHOULD throw a \cmisexceptionlink{constraint} exception if such an operation is not allowed.
Secondary object-types CAN NOT be used as primary object-types. That is, when an object is created, its object-type has to be either one of the other base types or an object-type that is derived from the other base types. Hence, a secondary object-type MUST NOT be creatable.

Whether an object is fileable, versionable or controllable is determined by its primary object-type. 


\subsubsection{Secondary Type Application}

\begin{sloppypar}
Secondary types can be applied at creation time by populating the multi-value property \texttt{cmis:secondaryObjectTypeIds} with the ids of the secondary types. All properties defined by these secondary types can be set as well.
\end{sloppypar}

Secondary types can be added and removed later by changing the \texttt{cmis:secondaryObjectTypeIds} property, either through the \cmisservicelink{updateProperties} service or the \cmisservicelink{checkIn} service. Adding the id of a secondary type to this multi value property adds the secondary type. Removing the id of a secondary type from this multi value property removes the type and all associated properties and values.

A repository MUST throw a \cmisexceptionlink{constraint} exception if a secondary type cannot be added or removed. 

Adding a secondary type and providing values for the associated properties of this secondary type MAY be done in the same operation.


\subsubsection{Secondary Object-Type Definition}

This section describes the definition of the secondary object-type's attribute values. All attributes are listed by their id.  


\paragraph{Attribute Values}

The secondary object-type MUST have the following attribute values.

Notes:
\begin{itemize}
	\item A value of <repository-specific> indicates that the value of the property MAY be set to any valid value for the attribute type.
	\item Unless explicitly stated otherwise, all values specified in the list MUST be followed for the object-type definition.
\end{itemize}

\cmisattributevalue{id}{cmis:secondary}

\cmisattributevalue{localName}{<repository-specific>}

\cmisattributevalue{localNamespace}{<repository-specific>}

\cmisattributevalue{queryName}{cmis:secondary}

\cmisattributevalue{displayName}{<repository-specific>}

\cmisattributevalue{baseId}{cmis:secondary}

\cmisattributevalue{parentId}{MUST NOT be set}

\cmisattributevalue{description}{<repository-specific>}

\cmisattributevalue{creatable}{FALSE}

\cmisattributevalue{fileable}{FALSE}

\cmisattributevalue{queryable}{<repository-specific>}

\cmisattributevalue{controllablePolicy}{FALSE}

\cmisattributevalue{controllableACL}{FALSE}

\cmisattributevalue{includedInSupertypeQuery}{<repository-specific>}

\cmisattributevalue{fulltextIndexed}{<repository-specific>\newline Note: This attribute defines if the properties of this secondary type are full-text indexed. It does not make a statement about the content.}


\paragraph{Property Definitions}

The secondary base object-type has no properties. Repositories MAY provide custom property definitions.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Object-Type Creation, Modification and Deletion
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\subsection{Object-Type Creation, Modification and Deletion}
\label{dm:typemutability}

A repository MAY support the creation, modification and deletion of primary and secondary object-types. 

Each object-type definition SHOULD include a set of flags that indicate if the object-type can be used as a parent type or if the object-type can be modified or deleted. Please see section \ref{dm:commontypeattributes}~\nameref{dm:commontypeattributes} for details.

These flags are not to be interpreted as the rights for the current user. These are the rights that would apply to an administrator user or a user that has sufficient rights to modify metadata. For example, a non-administrator would see that an object-type is extendable (the type mutability capabilities create flag is set to TRUE) even though they would not be allowed to actually perform the operation.  If a user tries to create, modify or delete a type definition and does not have the required permissions, the repository MUST return a \cmisexceptionlink{permissionDenied} error.

A repository MAY also place additional restrictions on these operations where necessary. These restrictions are repository specific.  


\subsubsection{General Constraints on Metadata Changes}
\label{dm:typemutabilityconstraints}

\begin{sloppypar}
The optional capabilities \texttt{capabilityNewTypeSettableAttributes} and \texttt{capabilityCreatablePropertyTypes} SHOULD indicate which object-type attributes can be set by a client and which properties data types can be used to create or extend an object-type.
\end{sloppypar}

Note, that the client CANNOT define whether a new object-type can be used as a parent type, or can be updated or deleted. How the repository determines a given object-type's mutability capabilities is repository specific.

When an object-type is created the client MUST suggest a type id for the new object-type. The repository may do the following with this suggested value:
\begin{itemize}
	\item Use it exactly as specified.\\e.g. input = invoice :  returned value = invoice
	\item Modify it with the addition of a prefix, suffix or both.\\e.g. input = invoice : returned value = invoice\_FAF5D0C5-BBE9
	\item Return a completely different value.\\e.g. input = invoice : returned value = FAF5D0C5-BBE9-4E47-BB17-C9FE63B4EE20
\end{itemize}

When a property definition is created the client MUST suggest a property definition id for the new property. The repository may do the following with this suggested value:
\begin{itemize}
	\item Use it exactly as specified.\\e.g. input = amount :  returned value = amount
	\item Modify it with the addition of a prefix, suffix or both.\\e.g. input = amount: returned value = amount\_12AB
	\item Return a completely different value.\\e.g. input = amount: returned value = 12AB-23CD
\end{itemize}

When an object-type is created or updated, the repository MUST return the created or updated type definition whereby the order of ALL newly created property definitions MUST match the order of the input. This is so that there will be no ambiguity for clients who need to know which property matches a specific suggested Id value for a new property definition. This special ordering is only required for the return value for \cmisservicelink{createType} and \cmisservicelink{updateType}. There is no special ordering of the properties returned for subsequent calls to \cmisservicelink{getTypeDefinition} for this new or modified type.

When an object-type is updated the following rules MUST be obeyed:
\begin{itemize}
	\item Inherited properties MUST NOT be modified. This includes constraints of any kind.
	\item Properties defined by the CMIS specification MUST NOT be modified. This includes constraints of any kind.
	\item Only leaf types may be modified. That is, if a type already has child types defined then it (and all of its properties and constraints) MUST be considered read only.
	\item Any added properties marked as "required" MUST have a default value.
	\item Required properties MAY be changed to optional. 
	\item Optional properties MUST NOT be changed to required.
	\item Property definitions MUST NOT be removed.  
	\item Property choice constraints MAY be changed in the following manner:
	\begin{itemize*}
		\item 'Open choice' MAY change from FALSE to TRUE.
		\item 'Open choice' MUST NOT change from TRUE to FALSE.
		\item Choices MAY be added or removed if 'open choice' is TRUE.
		\item Choices MUST NOT be removed if 'open choice' is FALSE.
	\end{itemize*}
	\item Validation constraints (min/max length, min/max value, etc.) on existing properties MAY be relaxed but they MUST NOT be further restricted. For example, an integer property value that originally had a minimum constraint of 100 and a maximum constraint of 1000 could change as follows:
	\begin{itemize*}
		\item A new minimum could be changed to 50 but could not be changed to 150. 
		\item A new maximum could be changed to 1100 but could not be changed to 900.  
	\end{itemize*}
	This ensures that the new constraints will not leave any existing data out of the permitted constraint range. 
	\item An existing property type's data type and cardinality MUST NOT be changed.  For example, an Integer property type MUST NOT be changed to a String. 
\end{itemize}

The execution of the \cmisservicelink{createType} and \cmisservicelink{updateType} services MUST not affect the definition of any other types or any other type's current property definitions. 
For example, any properties on the type being created must not place constraints on other type's properties when/if other properties 'share' property definitions.  

An object-type can only be deleted if there are no objects of this type and the object-type has no sub-types. The \cmisservicelink{deleteType} service MUST return a \cmisexceptionlink{constraint} error if an instance of the object-type exists or the object-type is a parent type of another object-type.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Object-Type Summary
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Object-Type Summary}

The following diagrams illustrate the CMIS object model. Please note that they only reflect the logical model. The CMIS bindings use slightly different data structures.

\cmisgraphics{cmis11-highlevel-uml}{width=1\textwidth}{CMIS Model}

\cmisgraphics{cmis11-types-uml}{width=1\textwidth}{CMIS Object Types and Property Types}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Access Control
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\subsection{Access Control}
\label{dm:accesscontrol}

A repository can support either a base set of CMIS-defined permissions and/or its own set of repository specific permissions. 

The \cmisservicelink{getACL} service allows the requestor to specify that the result be expressed using only the CMIS defined permissions. Without this restriction, the response may include, or be solely expressed in repository specific permissions. The \cmisservicelink{applyACL} service permits either CMIS permissions or repository permissions, or a combination of both, to be used.


\subsubsection{ACL, ACE, Principal, and Permission}

An \texttt{Access Control List (ACL)} is a list of \texttt{Access Control Entries (ACEs)} and MAY hold zero or more ACEs.  If an ACL has no ACEs, the behavior is the same as if the ACL is not set.

An ACE holds:
\begin{itemize}
	\item A \emph{principal} that represents a user management object, e.g.\ a user, group, or role. It holds one string with the \emph{principalId}.
	\item One or more strings with the names of the \emph{permissions}.
	\item A boolean flag \emph{\texttt{direct}} which indicates if TRUE that the ACE is directly assigned to the object. If FALSE, that the ACE is somehow derived or inherited.
\end{itemize}


\subsubsection{CMIS Permissions}

There are three basic permissions predefined by CMIS:
\begin{description}
	\item[cmis:read] Expresses the "permission to read" properties AND content of an object.
	\item[cmis:write] Expresses the "permission to write" properties AND content of an object. It MAY include the \texttt{cmis:read} permission.
	\item[cmis:all] SHOULD express all the permissions of a repository. It SHOULD include all other basic CMIS permissions.
\end{description}

How these basic permissions are mapped to the allowable actions is repository specific. However, the actual repository semantics for the basic permissions with regard to allowable actions can be discovered by the mappings parameter returned by the \cmisservicelink{getRepositoryInfo} service.

Repositories MAY extend this set with repository-specific permissions.


\subsubsection{ACL Capabilities}
\label{dm:aclcapabilities}

Whether a repository supports ACLs at all, may be discovered via \texttt{capabilityACL} attribute returned by the \cmisservicelink{getRepositoryInfo} service (see section \ref{dm:optionalcapabilities}~\nameref{dm:optionalcapabilities}). If the value of the \texttt{capabilityACL} attribute is \texttt{none}, ACLs are not supported by the repository.

If the value of the \texttt{capabilityACL} attribute is \texttt{discover} or \texttt{manage}, additional information about the repository's permission model and how ACL modifications are handled are provided by the \cmisservicelink{getRepositoryInfo} service:
\begin{description}
	\item[Enum propagation] specifies how non-direct ACEs can be handled by the repository using the following values (see section \cmisserviceref{applyACL}):
	\begin{description}
		\item[objectonly] indicates that the repository is able to apply ACEs to an object without changing the ACLs of other objects.
		\item[propagate] indicates that the ACEs might be inherited by other objects. \texttt{propagate} includes the support for  \texttt{objectonly}.
		\item[repositorydetermined] indicates that the repository has its own mechanism of computing how changing an ACL for an object influences the non-direct ACEs of other objects.
	\end{description}
	\item[<Array> PermissionDefinition repositoryPermissions] A list of names and descriptions of the supported permissions.
	\item[<Array> PermissionMapping mappings] Contains a list of basic CMIS permissions to allowable actions mapping.
\end{description}


\paragraph{Supported Permissions}
\label{dm:aclsupportedpermissions}

The list of permission definitions returned by the \cmisservicelink{getRepositoryInfo} service lists all the permissions a repository supports. This list also includes the CMIS permissions if supported by the repository.

A PermissionDefinition holds:
\begin{description}
	\item[String permission] The (technical) name of the permission. Permission names MUST be unique within the permission definition list.
	\item[String description] An optional description of the permission that SHOULD be used as the permission's name to be presented to the user.
\end{description}


\paragraph{AllowableActions and Permission Mapping}

CMIS provides a mechanism called \emph{Allowable Actions} which allows an application to discover the set of service operations that can currently be performed on a particular object by the current user, without having to actually invoke the service. 

The set of allowable actions on an object at a point in time are affected not only by CMIS ACLs, but also by other factors such as: 
\begin{itemize}
	\item Constraints inherent in the CMIS Domain Model based on the object's base type or current versioning state. 
	\item Policies or other control mechanisms that are opaque to CMIS. 
\end{itemize}

CMIS defines several services that applications can use at run-time to discover the allowable actions for an object.

If a repository supports ACLs, then the repository MUST provide a mapping table that defines how the permissions supported by the repository interact with the CMIS allowable actions, i.e.\ which permissions are necessary for a principal to have on one or more objects in order to potentially perform each action, subject to the other constraints on allowable actions mentioned above. 

This section defines both the allowable actions as well as how those actions are presented in the permission mapping table.  

The permission mapping table contains a set of \emph{key--permissions} pairs:
\begin{description}
	\item[String key] Since several allowable actions require permissions on more than one object, the mapping table is defined in terms of permission "keys". (For example, moving a document from one folder to another may require permissions on the document and each of the folders.) Each key combines the name of the allowable action and the object for which the principal needs the required permission.\\
For example, the \texttt{canMoveObject.Source} key indicates the permissions that the principal must have on the "source folder" to move an object from that folder into another folder. 
	\item[<Array> String permissions] The name of one or more permissions that the principal MUST have. If more than one permission is specified, then the principal MUST be allowed to perform the operation if they have ANY of the listed permissions.
\end{description}
 
The following list defines all mapping keys, as well as a permissions mapping that repositories SHOULD use. Repositories MAY require additional permissions.  

For convenience, the list groups all mapping entries by the underlying allowable actions, and includes descriptive information. For each allowable action the following information is given:
\begin{description}
	\item[Description] The description and name of the service the allowable action enables.
	\item[Base Type] The base object-types for which the allowable action MAY be TRUE.
	\item[Operand] The object the permission applies to.
	\item[Key] The permission mapping key.
	\item[Permissions] The permission values.
\end{description}


\subparagraph{Navigation Services}

\begin{cmisallowableaction}{canGetDescendants}
	\cmisallowableactiondetail{Description}{Can get the descendants of the folder (\cmisservicelink{getDescendants} and \cmisservicelink{getFolderTree}).}
	\cmisallowableactiondetail{Base Type}{cmis:folder}
	\cmisallowableactiondetail{Operand}{Folder}
	\cmisallowableactiondetail{Key}{canGetDescendants.Folder}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canGetChildren}
	\cmisallowableactiondetail{Description}{Can get the children of the folder (\cmisservicelink{getChildren}).}
	\cmisallowableactiondetail{Base Type}{cmis:folder}
	\cmisallowableactiondetail{Operand}{Folder}
	\cmisallowableactiondetail{Key}{canGetChildren.Folder}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canGetFolderParent}
	\cmisallowableactiondetail{Description}{Can get the parent folder of the folder (\cmisservicelink{getFolderParent}).}
	\cmisallowableactiondetail{Base Type}{cmis:folder}
	\cmisallowableactiondetail{Operand}{Folder}
	\cmisallowableactiondetail{Key}{canGetFolderParent.Object}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canGetObjectParents}
	\cmisallowableactiondetail{Description}{Can get the parent folders of the object (\cmisservicelink{getObjectParents}).}
	\cmisallowableactiondetail{Base Type}{cmis:document, cmis:policy, cmis:item}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canGetParents.Folder}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}


\subparagraph{Object Services}

\begin{cmisallowableaction}{canCreateDocument}
	\cmisallowableactiondetail{Description}{Can create a cmis:document object in the specified folder (\cmisservicelink{createDocument}).}
	\cmisallowableactiondetail{Base Type}{cmis:folder}
	\cmisallowableactiondetail{Operand}{Folder}
	\cmisallowableactiondetail{Key}{canCreateDocument.Folder}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canCreateFolder}
	\cmisallowableactiondetail{Description}{Can create a cmis:folder object as a child of the specified folder (\cmisservicelink{createFolder}).}
	\cmisallowableactiondetail{Base Type}{cmis:folder}
	\cmisallowableactiondetail{Operand}{Folder}
	\cmisallowableactiondetail{Key}{canCreateFolder.Folder}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canCreatePolicy}
	\cmisallowableactiondetail{Description}{Can create a cmis:policy object as a child of the specified folder (\cmisservicelink{createPolicy}).}
	\cmisallowableactiondetail{Base Type}{cmis:folder}
	\cmisallowableactiondetail{Operand}{Folder}
	\cmisallowableactiondetail{Key}{canCreatePolicy.Folder}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canCreateRelationship}
	\cmisallowableactiondetail{Description}{Can create a relationship object with the object as its source (\cmisservicelink{createRelationship}).}
	\cmisallowableactiondetail{Base Type}{cmis:document, cmis:folder, cmis:policy, cmis:item}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canCreateRelationship.Source}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canCreateRelationship}
	\cmisallowableactiondetail{Description}{Can create a relationship object with the object as its target (\cmisservicelink{createRelationship}).}
	\cmisallowableactiondetail{Base Type}{cmis:document, cmis:folder, cmis:policy, cmis:item}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canCreateRelationship.Target}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canGetProperties}
	\cmisallowableactiondetail{Description}{Can read the properties of the specified object (\cmisservicelink{getProperties}, \cmisservicelink{getObject} and \cmisservicelink{getObjectByPath}).}
	\cmisallowableactiondetail{Base Type}{cmis:document, cmis:folder, cmis:relationship, cmis:policy, cmis:item}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canGetProperties.Object}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canUpdateProperties}
	\cmisallowableactiondetail{Description}{Can update the properties of  the specified  object (\cmisservicelink{updateProperties}).}
	\cmisallowableactiondetail{Base Type}{cmis:document, cmis:folder, cmis:relationship, cmis:policy, cmis:item}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canUpdateProperties.Object}
	\cmisallowableactiondetail{Permission}{cmis:write}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canMoveObject}
	\cmisallowableactiondetail{Description}{Can move the specified object (\cmisservicelink{moveObject}).}
	\cmisallowableactiondetail{Base Type}{cmis:document, cmis:folder, cmis:policy, cmis:item}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canMove.Object}
	\cmisallowableactiondetail{Permission}{cmis:write}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canMoveObject}
	\cmisallowableactiondetail{Description}{Can move an object into this folder (\cmisservicelink{moveObject}).}
	\cmisallowableactiondetail{Base Type}{cmis:folder}
	\cmisallowableactiondetail{Operand}{Folder}
	\cmisallowableactiondetail{Key}{canMove.Target}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canMoveObject}
	\cmisallowableactiondetail{Description}{Can move an object from this folder (\cmisservicelink{moveObject}).}
	\cmisallowableactiondetail{Base Type}{cmis:folder}
	\cmisallowableactiondetail{Operand}{Folder}
	\cmisallowableactiondetail{Key}{canMove.Source}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canDeleteObject}
	\cmisallowableactiondetail{Description}{Can delete the specified object (\cmisservicelink{deleteObject}).}
	\cmisallowableactiondetail{Base Type}{cmis:document, cmis:folder, cmis:relationship, cmis:policy, cmis:item}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canDelete.Object}
	\cmisallowableactiondetail{Permission}{cmis:write}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canGetContentStream}
	\cmisallowableactiondetail{Description}{Can get the content stream for the document object (\cmisservicelink{getContentStream}).}
	\cmisallowableactiondetail{Base Type}{cmis:document}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canViewContent.Object}
	\cmisallowableactiondetail{Permission}{cmis:write}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canSetContentStream}
	\cmisallowableactiondetail{Description}{Can set the content stream for the document object  (\cmisservicelink{setContentStream}).}
	\cmisallowableactiondetail{Base Type}{cmis:document}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canSetContent.Document}
	\cmisallowableactiondetail{Permission}{cmis:write}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canDeleteContentStream}
	\cmisallowableactiondetail{Description}{Can delete the content stream for the Document object (\cmisservicelink{deleteContentStream}).}
	\cmisallowableactiondetail{Base Type}{cmis:document}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canDeleteContent.Document}
	\cmisallowableactiondetail{Permission}{cmis:write}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canDeleteTree}
	\cmisallowableactiondetail{Description}{Can delete the specified folder and all contained objects (\cmisservicelink{deleteTree}).}
	\cmisallowableactiondetail{Base Type}{cmis:folder}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canDeleteTree.Folder}
	\cmisallowableactiondetail{Permission}{cmis:write}
\end{cmisallowableaction}


\subparagraph{Filing Services}

\begin{cmisallowableaction}{canAddObjectToFolder}
	\cmisallowableactiondetail{Description}{Can file the object in a folder (\cmisservicelink{addObjectToFolder}).}
	\cmisallowableactiondetail{Base Type}{cmis:document, cmis:policy, cmis:item}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canAddToFolder.Object}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canAddObjectToFolder}
	\cmisallowableactiondetail{Description}{Can file an object in the specified folder (\cmisservicelink{addObjectToFolder}).}
	\cmisallowableactiondetail{Base Type}{cmis:document, cmis:policy, cmis:item}
	\cmisallowableactiondetail{Operand}{Folder}
	\cmisallowableactiondetail{Key}{canAddToFolder.Folder}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canRemoveObjectFromFolder}
	\cmisallowableactiondetail{Description}{Can unfile the specified document from a folder (\cmisservicelink{removeObjectFromFolder}).}
	\cmisallowableactiondetail{Base Type}{cmis:document, cmis:policy, cmis:item}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canRemoveFromFolder.Object}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canRemoveObjectFromFolder}
	\cmisallowableactiondetail{Description}{Can unfile an object from the specified folder (\cmisservicelink{removeObjectFromFolder}).}
	\cmisallowableactiondetail{Base Type}{cmis:document, cmis:policy}
	\cmisallowableactiondetail{Operand}{Folder}
	\cmisallowableactiondetail{Key}{canRemoveFromFolder.Folder}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}


\subparagraph{Versioning Services}

\begin{cmisallowableaction}{canCheckOut}
	\cmisallowableactiondetail{Description}{Can check out the specified document (\cmisservicelink{checkOut}).}
	\cmisallowableactiondetail{Base Type}{cmis:document}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canCheckout.Document}
	\cmisallowableactiondetail{Permission}{cmis:write}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canCancelCheckOut}
	\cmisallowableactiondetail{Description}{Can cancel the check out the specified PWC (\cmisservicelink{cancelCheckOut}).}
	\cmisallowableactiondetail{Base Type}{cmis:document}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canCancelCheckout.Document}
	\cmisallowableactiondetail{Permission}{cmis:write}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canCheckIn}
	\cmisallowableactiondetail{Description}{Can check in the specified PWC (\cmisservicelink{checkIn}).}
	\cmisallowableactiondetail{Base Type}{cmis:document}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canCheckin.Document}
	\cmisallowableactiondetail{Permission}{cmis:write}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canGetAllVersions}
	\cmisallowableactiondetail{Description}{Can get the version series of the specified document (\cmisservicelink{getAllVersions}).}
	\cmisallowableactiondetail{Base Type}{cmis:document}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canGetAllVersions.VersionSeries}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}


\subparagraph{Relationship Services}

\begin{cmisallowableaction}{canGetObjectRelationships}
	\cmisallowableactiondetail{Description}{Can get the relationship in which this object is a source  or a target (\cmisservicelink{getObjectRelationships}).}
	\cmisallowableactiondetail{Base Type}{cmis:document, cmis:folder, cmis:policy, cmis:item}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canGetObjectRelationships.Object}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}


\subparagraph{Policy Services}

\begin{cmisallowableaction}{canApplyPolicy}
	\cmisallowableactiondetail{Description}{Can apply a policy to the specified object (\cmisservicelink{applyPolicy}).}
	\cmisallowableactiondetail{Base Type}{cmis:document, cmis:folder, cmis:policy, cmis:relationship, cmis:item}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canAddPolicy.Object}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canApplyPolicy}
	\cmisallowableactiondetail{Description}{Can apply the specified policy to an object (\cmisservicelink{applyPolicy}).}
	\cmisallowableactiondetail{Base Type}{cmis:policy}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canAddPolicy.Policy}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canRemovePolicy}
	\cmisallowableactiondetail{Description}{Can remove a policy from the specified object (\cmisservicelink{removePolicy}).}
	\cmisallowableactiondetail{Base Type}{cmis:document, cmis:folder, cmis:policy, cmis:relationship, cmis:item}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canRemovePolicy.Object}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canRemovePolicy}
	\cmisallowableactiondetail{Description}{Can remove the specified policy from an object  (\cmisservicelink{removePolicy}).}
	\cmisallowableactiondetail{Base Type}{cmis:policy}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canRemovePolicy.Policy}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canGetAppliedPolicies}
	\cmisallowableactiondetail{Description}{Can get the list of policies applied to the specified object (\cmisservicelink{getAppliedPolicies}).}
	\cmisallowableactiondetail{Base Type}{cmis:document, cmis:folder, cmis:policy, cmis:relationship, cmis:item}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canGetAppliedPolicies.Object}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}


\subparagraph{ACL Services}

\begin{cmisallowableaction}{canGetACL}
	\cmisallowableactiondetail{Description}{Can get ACL of the specified object (\cmisservicelink{getACL}).}
	\cmisallowableactiondetail{Base Type}{cmis:document, cmis:folder, cmis:relationship, cmis:policy, cmis:item}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canGetACL.Object}
	\cmisallowableactiondetail{Permission}{cmis:read}
\end{cmisallowableaction}

\begin{cmisallowableaction}{canApplyACL}
	\cmisallowableactiondetail{Description}{Can apply ACL to this object (\cmisservicelink{applyACL}).}
	\cmisallowableactiondetail{Base Type}{cmis:document, cmis:folder, cmis:relationship, cmis:policy, cmis:item}
	\cmisallowableactiondetail{Operand}{Object}
	\cmisallowableactiondetail{Key}{canApplyACL.Object}
	\cmisallowableactiondetail{Permission}{cmis:write}
\end{cmisallowableaction}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Versioning
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\subsection{Versioning}
\label{dm:versioning}

CMIS supports versioning of document objects. Folder objects, relationship objects, policy objects, and item objects cannot be versioned.
 
Whether or not a document object is versionable (i.e.\ whether or not operations performed on the object via the Versioning Services MUST be allowed) is specified by the "versionable" attribute on its object-type.

A \emph{version} of a document object is an explicit/"deep" copy of the object, preserving its state at a certain point in time. Each version of a document object is itself a document object, i.e.\ has its own object id, property values, MAY be acted upon using all CMIS services that act upon document objects, etc.


\subsubsection{Version Series}

A \emph{version series} for a document object is a transitively closed collection of all document objects, other than any Private Working Copy (see section \ref{dm:checkout}~\nameref{dm:checkout}), that have been created from an original document in the repository. Each version series has a unique, system-assigned, and immutable \emph{version series id}. 

The version series has transitive closure -- that is, if object B is a version of object A, and object C is a version of object B, then object C is also a version of object A. The objects in a version series can be conceptually sequenced by their respective creation date properties (\texttt{cmis:creationDate}).

Additionally, the repository MAY expose a textual \emph{version label} (\texttt{cmis:versionLabel}) that describes to a user the position of an individual object with respect to the version series. (For example, version 1.0). 

Note: A document object that is NOT versionable will always have a single object in its version series. A versionable document object MAY have one or more objects in its version series. 


\subsubsection{Latest Version}

The version that has the most recent last modification date (\texttt{cmis:lastModificationDate}) is called the \emph{latest version} of the series, or equivalently, the latest version of any document object in the series.

When the latest version of a version series is deleted, a previous version (if there is one) becomes the latest version. 


\subsubsection{Behavioral constraints on non-Latest Versions}

Repositories NEED NOT allow the non-latest versions in a version series to be updated, queried, or searched. 


\subsubsection{Major Versions}

A document object in a version series MAY be designated as a \emph{major version}.
 
The CMIS specification does not define any semantic/behavioral differences between major and non-major versions in a version series. Repositories may enforce/apply additional constraints or semantics for major versions, if the effect on CMIS services remains consistent with an allowable behavior of the CMIS model.

If the version series contains one or more major versions, the one that has the most recent last modification date (property \texttt{cmis:lastModificationDate}) is the \emph{latest major version} of the version series. 

(Note that while a version series MUST always have a latest version, it NEED NOT have a latest major version.)

When the latest major version is deleted, a previous major version (if there is one) becomes the latest major version.


\subsubsection{Services that modify Version Series}


\paragraph{Checkout}
\label{dm:checkout}

A new version of a versionable document object is created when the \cmisservicelink{checkIn} service is invoked on the \emph{Private Working Copy (PWC)} of this object. A PWC is created by invoking \cmisservicelink{checkOut} on a versionable document object. A repository MAY allow any document object in a version series to be checked out, or MAY only allow the latest version to be checked out.\\

The effects of invoking the \cmisservicelink{checkOut} service MUST be as follows:
\begin{itemize}
	\item A new document object, referred to herein as the \emph{Private Working Copy (PWC)}, is created. The object id of this new document object MUST be unique and MUST NOT be equal to the id of the object on which the \cmisservicelink{checkOut} service was invoked.
	\item The PWC NEED NOT be visible to users who have permissions to view other document objects in the version series. 
	\item The value of the \texttt{cmis:isPrivateWorkingCopy} property MUST be TRUE.
	\item The PWC is NOT to be considered a version in the version series but inherits the version series id from the document it was created from.
	\item Therefore, until it is checked in (using the \cmisservicelink{checkIn} service), the PWC MUST NOT be considered the latest or latest major version in the version series. That is, the values of the \texttt{cmis:isLatestVersion} and \texttt{cmis:isLatestMajorVersion} properties MUST be FALSE.
	\item The property values for the PWC SHOULD be identical to the properties of the document object on which the \cmisservicelink{checkOut} service was invoked. Certain properties may be different.  Properties such as \texttt{cmis:creationDate} most likely will be different. The content stream of the PWC MAY be identical to the content stream of the document object on which the \cmisservicelink{checkOut} service was invoked, or MAY be "not set". 
\end{itemize}

After a successful \cmisservicelink{checkOut} operation is completed, and until such time when the PWC is deleted (via the \cmisservicelink{cancelCheckOut} service) or checked-in (via the \cmisservicelink{checkIn} service), the effects on the PWC or on other documents in the version series MUST be as follows:
\begin{itemize}
	\item The repository MUST throw an exception if the \cmisservicelink{checkOut} service is invoked on any document in the version series. (I.e.\ there can only be one PWC for a version series at a time.)
	\item The value of the \texttt{cmis:isVersionSeriesCheckedOut} property MUST be TRUE.
	\item The value of the \texttt{cmis:versionSeriesCheckedOutBy} property SHOULD be set to a value indicating which user created the PWC. (The repository MAY still show the "not set" value for this property if, for example, the information is not available or the current user has not sufficient permissions.)
	\item The value of the \texttt{cmis:versionSeriesCheckedOutId} property SHOULD be set to the object id of the PWC. (The repository MAY still show the "not set" value for this property if the current user has no permissions to see the PWC). 
	\item The repository MAY prevent operations that modify or delete the other documents in the version series. 
\end{itemize}


\paragraph{Updates to the Private Working Copy}

If the repository supports the optional "PWCUpdatable" capability, then the repository MUST allow authorized users to modify the PWC object using the object services (e.g.\ \cmisservicelink{updateProperties} and \cmisservicelink{setContentStream}). 

If the repository does NOT support the "PWCUpdatable" capability, then the PWC object can only be modified as part of the \cmisservicelink{checkIn} service call. 


\paragraph{Discarding Check out}
\label{dm:discardingcheckout}

An authorized user MAY discard the check-out using the \cmisservicelink{cancelCheckOut} service on the PWC object or by using the \cmisservicelink{deleteObject} service on the PWC object. The effects of discarding a check-out MUST be as follows:
\begin{itemize}
	\item The PWC Object MUST be deleted.
	\item For all other documents in the version series:
	\begin{itemize}
		\item The value of the \texttt{cmis:isVersionSeriesCheckedOut} property MUST be FALSE.
		\item The value of the \texttt{cmis:versionSeriesCheckedOutBy} property MUST be "not set". 
		\item The value of the \texttt{cmis:versionSeriesCheckedOutId} property MUST be "not set".
		\item The repository MUST allow authorized users to invoke the \cmisservicelink{checkOut} service. 
	\end{itemize}
\end{itemize}


\paragraph{Checkin}
\label{dm:checkin}

An authorized user MAY "check in" the Private Working Copy object via the \cmisservicelink{checkIn} service.

The \cmisservicelink{checkIn} service allows users to provide update property values and a content stream for the PWC object.\\
 
The effects of the \cmisservicelink{checkIn} service MUST be as follows for successful checkins:
\begin{itemize}
	\item The PWC object MUST be updated as specified by the inputs to the \cmisservicelink{checkIn} service. (Note that for repositories that do NOT support the "PWCUpdatable" property, this is the only way to update the PWC object.)
	\item The document object resulting from the \cmisservicelink{checkIn} service MUST be considered the latest version in the version series.
	\item If the inputs to the checkIn service specified that the PWC MUST be a "major version", then the newly created version MUST be considered the latest major version in the version series. 
	\item If the check-in returns a new \texttt{cmis:objectId}, then the PWC object MUST disappear if the \cmisservicelink{checkIn}  call was successful and the new checked in version will use the new specified id.
	\item For all documents in the version series:
	\begin{itemize}
		\item The value of the \texttt{cmis:isVersionSeriesCheckedOut} property MUST be FALSE.
		\item The value of the \texttt{cmis:versionSeriesCheckedOutBy} property MUST be "not set". 
		\item The value of the \texttt{cmis:versionSeriesCheckedOutId} property MUST be "not set".
		\item The repository MUST allow authorized users to invoke the \cmisservicelink{checkOut} service. 
	\end{itemize}
\end{itemize}

Note: A repository MAY automatically create new versions of document objects without an explicit invocation of the \cmisservicelink{checkOut}/\cmisservicelink{checkIn} services. 


\subsubsection{Versioning Properties on Document Objects}
\label{dm:versioningproperties}

All document objects will have the following read-only property values pertaining to versioning:\\

\begin{cmisversionproperty}{cmis:isPrivateWorkingCopy}{Boolean}
TRUE if the document object is a Private Working Copy.  FALSE otherwise.
\end{cmisversionproperty}

\begin{cmisversionproperty}{cmis:isLatestVersion}{Boolean}
TRUE if the document object is the latest version (most recent last modification date) in its version series.  FALSE otherwise. MUST be FALSE for Private Working Copy objects.
\end{cmisversionproperty}

\begin{cmisversionproperty}{cmis:isMajorVersion}{Boolean}
TRUE if the document object is a major version in its version series.  FALSE otherwise. MUST be FALSE for Private Working Copy objects.
\end{cmisversionproperty}

\begin{cmisversionproperty}{cmis:isLatestMajorVersion}{Boolean}
TRUE if the document object is the latest major version in its version series.  FALSE otherwise. MUST be FALSE for Private Working Copy objects.
\end{cmisversionproperty}

\begin{cmisversionproperty}{cmis:versionLabel}{String}
Textual description the position of an individual object with respect to the version series.  (For example, "version 1.0"). MAY be "not set".
\end{cmisversionproperty}

\begin{cmisversionproperty}{cmis:versionSeriesId}{Id}
Id of the version series for this object.
\end{cmisversionproperty}

\begin{cmisversionproperty}{cmis:isVersionSeriesCheckedOut}{Boolean}
TRUE if there currenly exists a Private Working Copy for this version series.  FALSE otherwise.
\end{cmisversionproperty}

\begin{cmisversionproperty}{cmis:versionSeriesCheckedOutBy}{String}
If \texttt{cmis:isVersionSeriesCheckedOut} is TRUE:  An identifier for the user who created the Private Working Copy.  "Not set" otherwise.
\end{cmisversionproperty}

\begin{cmisversionproperty}{cmis:versionSeriesCheckedOutId}{String}
If \texttt{cmis:isVersionSeriesCheckedOut} is TRUE:  The object id for the Private Working Copy.  "Not set" otherwise.
\end{cmisversionproperty}

\begin{cmisversionproperty}{cmis:checkinComment}{String}
Textual comment associated with the given version. MAY be "not set".
\end{cmisversionproperty}

\begin{sloppypar}
Note: Changes made via the Versioning Services that affect the values of these properties MUST NOT constitute modifications to the document objects in the version series (e.g.\ MUST NOT affect the \texttt{cmis:lastModificationDate}, etc.).
\end{sloppypar}
 

\subsubsection{Document Creation and Initial Versioning State}

\begin{sloppypar}
When calling the \cmisservicelink{createDocument} service or the \cmisservicelink{createDocumentFromSource} service, a \texttt{versioningState} parameter can be used to specify what the versioning state of the newly-created object MUST be.
\end{sloppypar}

A repository MAY create new document objects in a "Private Working Copy" state. This state is logically equivalent to having a version series that contains exactly one object (the PWC) and 0 other documents. 

The repository MAY also create new document objects in a "major version" state. This state is logically equivalent to having a version series that contains exactly one major version and 0 other documents.

The repository MAY also create new document objects in a "non-major version" state. This state is logically equivalent to having a version series that contains exactly one non-major version and 0 other documents.

If the repository does not support versioning the repository MUST ignore the value of the \texttt{versioningState} parameter.


\subsubsection{Version Specific/Independent membership in Folders}

Repositories MAY treat membership of a document object in a folder collection as "version-specific" or "version-independent". 
 
Repositories MUST indicate whether they support version-specific membership in a folder via the "capabilityVersionSpecificFiling" optional capability flag. (See section \ref{dm:optionalcapabilities}~\nameref{dm:optionalcapabilities}.)

If the repository is treating folder collection membership as "version-independent", then:
\begin{itemize}
	\item Moving or filing a document object into a folder MUST result in ALL documents in the version series being moved/filed into the folder.
	\item The repository MAY return only the latest-version OR latest major-version document object in a version series in the response to Navigation service requests (\cmisservicelink{getChildren}, \cmisservicelink{getDescendants}), and NEED NOT return other document objects filed in the folder that are in the version series. 
\end{itemize}

If the repository is treating folder collection membership as "version-specific", then moving or filing a document object into a folder MUST NOT result in other documents in the version series being moved/filed. 


\subsubsection{Version Specific/Independent membership in Relationships}

A relationship object MAY have either a version-specific or version-independent binding to its source and/or target objects. This behavior MAY vary between repositories and between individual relationship types defined for a repository.

If a relationship object has a version-independent binding to its source/target object, then:
\begin{itemize}
	\item The \cmisservicelink{getObjectRelationships} service invoked on a document object MUST return the relationship if relationship was source/target is set to ANY Document Object in the version series.
\end{itemize}

If a relationship object has a version-specific binding to its source/target object, then:
\begin{itemize}
	\item The \cmisservicelink{getObjectRelationships} service invoked on a document object MUST return the relationship if relationship was source/target is set to the id of the document object on which the service was invoked.
\end{itemize}


\subsubsection{Versioning visibility in Query Services}

Repositories MAY include non-latest-versions of document objects in results to the \cmisservicelink{query} service. 

Repositories MUST indicate whether they support querying for non-latest-versions via the "capabilityAllVersionsSearchable" optional capability flag. (See section \ref{dm:optionalcapabilities}~\nameref{dm:optionalcapabilities}.)
 
If "capabilityAllVersionsSearchable" is TRUE then the repository MUST include in the query results ANY document object in the version series that matches the query criteria. (Subject to other query constraints such as security.)

Additionally, repositories MAY include Private Working Copy objects in results to the \cmisservicelink{query} service. 
Repositories MUST indicate whether they support querying for Private Working Copy objects via the "capabilityPWCSearchable" optional capability flag. 

If "capabilityPWCSearchable" is TRUE then the repository MUST include in the query results ANY Private Working Copy Document objects that matches the query criteria. (Subject to other query constraints such as security.)

If "capabilityPWCSearchable" is FALSE then the repository MUST NOT include in the query results ANY Private Working Copy Document Objects that match the query criteria. (Subject to other query constraints such as security.)


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Query
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\input{query.tex}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Change Log
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Change Log}
\label{dm:changelog}

CMIS provides a "change log" mechanism, the \cmisservicelink{getContentChanges} service, to allow applications to easily discover the set of changes that have occurred to objects stored in the repository since a previous point in time. This change log can then be used by applications such as search services that maintain an external index of the repository to efficiently determine how to synchronize their index to the current state of the repository (rather than having to query for all objects currently in the repository).

Entries recorded in the change log are referred to below as "change events".

Note that change events in the change log MUST be returned in ascending order from the time when the change event occurred.


\subsubsection{Completeness of the Change Log}

The change log mechanism exposed by a repository MAY be able to return an entry for every change ever made to content in the repository, or may only be able to return an entry for all changes made since a particular point in time. This "completeness" level of the change log is indicated via the \texttt{changesIncomplete} value found on the \cmisservicelink{getRepositoryInfo} service response.

However, repositories MUST ensure that if an application requests the entire contents of the repository's change log, that the contents of the change log includes ALL changes made to any object in the repository after the first change listed in the change log. (I.e.\ repositories MAY truncate events from the change log on a "first-in first-out" basis, but not in any other order.)

A repository MAY record events such as filing/unfiling/moving of documents as change events on the documents, their parent folder(s), or both the documents and the parent folders. 


\subsubsection{Change Log Token}

The primary index into the change log of a repository is the "change log token". The change log token is an opaque string that uniquely identifies a particular change in the change log.  


\subsubsection{"Latest Change Token" repository information}

Repositories that support the changeLogToken event MUST expose the latest change log token (i.e.\ the change log token corresponding to the most recent change to any object in the repository) as a property returned by the \cmisservicelink{getRepositoryInfo} service.

This will enable applications to begin "subscribing" to the change log for a repository by discovering what change log token they should use on a going-forward basis to discover change events to the repository.


\subsubsection{Change Event}
\label{dm:changeevent}

A change event represents a single action that occurred to an object in the repository that affected the persisted state of the object.

A repository that supports the change log capability MUST expose at least the following information for each change object:
\begin{description}
	\item[Id ObjectId] The object id of the object to which the change occurred.
	\item[Enum ChangeType] An enumeration that indicates the type of the change. Valid values are:
	\begin{description}
		\item[created] The object was created.
		\item[updated] The object was updated.
		\item[deleted] The object was deleted.
		\item[security] The access control or security policy for the object were changed.
	\end{description}
	\item[<Properties> properties] Additionally, for events of changeType "updated", the repository MAY optionally include the new values of properties on the object (if any).
\end{description}

Repositories MUST indicate whether they include properties for "updated" change events via the optional \texttt{capabilityChanges}.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Retentions and Holds 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\subsection{Retentions and Holds}
\label{dm:renditionsandholds}

Retentions and Holds can be used to protect documents from being deleted or modified. A Retention describes a period of time where the document must not be deleted, while a Hold just marks the document as protected as long as the Hold is applied to a document. 

This specification defines a basic interface for end user operations. Administrative operations such as managing a file plan or shortening retention periods are out of scope. A repository MAY support settings that require administrative privileges and bend the rules described in the following section. The implications are repository specific. 

Retentions and Holds can be applied to documents by applying predefined secondary types for Retentions and Holds. CMIS specifies secondary types for:

\begin{itemize}
	\item Repository Managed Retentions
	\item Client Managed Retentions (with a subtype for Destruction Retentions)
	\item Holds
\end{itemize}
 
If a repository does not support one of the predefined types for Retention and Hold management, the corresponding secondary type MUST NOT be returned by a \cmisservicelink{getTypeChildren} service call.
 
All secondary types for retention and hold management SHOULD be able to be applied to objects derived from the \texttt{cmis:document} base type. Applying such types to other CMIS objects and its behavior is repository specific. A repository MUST throw a \cmisexceptionlink{constraint} exception if the operation is not supported.
 
Retentions and Holds are applied to document versions. How this affects other versions in the version series is repository specfic.

Retentions and Holds protect at least the content of a document from modifications. If this protection also applies to the properties, ACL, policies, relationships, etc. of a document, is repository specific. Clients may use the Allowable Actions to discover what they can do with protected documents.


\subsubsection{Repository Managed Retentions}

Repository Managed Retentions are used in scenarios where the repository is responsible for calculating the concrete expiration date and potential destruction date for a document. As a first step a records manager usually creates a file plan in the repository and assigns rules which are used to calculate the retention period for a specific entry in the file plan. Creating a file plan is out-of-scope for CMIS. It has to be done using the native (user) interfaces of the repository. In order to enable a client to classify documents according to this file plan, the repository exposes the file plan as a secondary type hierarchy. The CMIS client can now apply one of the exposed file plan categories to a document. This process is called classification:


\cmisgraphics{fileplan}{width=1\textwidth}{Classification}

Support for Repository Managed Retentions is optional. A repository that does not support Repository Managed Retentions will not expose a file plan via the secondary type hierarchy. Repositories that support Repository Managed Retentions MUST expose the categories of the file plan as a subtype of the CMIS defined secondary type \texttt{cmis:rm\_repMgtRetention}. The secondary type \texttt{cmis:rm\_repMgtRetention} does not require any properties. A repository MAY add repository specific properties. A secondary type hierarchy for Repository Managed Retentions could look like this (white boxes are CMIS defined types, orange boxes are repository specific):


\cmisgraphics{repmgtretention}{width=1\textwidth}{Repository Managed Retentions Types}
%\begin{figure}[htb]
%\centering
%\includegraphics[width=1\textwidth]{repmgtretention.pdf}
%\caption{Repository Managed Retentions Types}
%\end{figure}

The usage of Repository Managed Retentions allows support of support advanced scenarios where the retention period is not fixed at creation time, but managed more dynamically (e.g. depending on certain property changes like "3 years after setting status to released"). The capabilities that are kind of rules are supported and how they are enforced varies widely between repository implementations. Some may do this automatically, some may require manually triggered batch runs, require an approval or workflow for certain actions etc. This model has minimal requirements for the application but can use much of the functionality that a repository provides.

This specification only defines the classification process, that is applying a Repository Managed Retention to a document. Creating and managing the rules and how rules are mapped to file plan categories is out-of-scope and repository specific. Which set of Repository Managed Retentions can be assigned to which objects is also repository specific.

Whether a user is allowed to apply a Repository Managed Retention is repository specific. If the user has no permission to do so, a \cmisexceptionlink{permissionDenied} exception MUST be thrown. In case of others constraints, a \cmisexceptionlink{constraint} exception MUST be thrown.


\paragraph {Repository Managed Retention Type}

\subparagraph{Attribute Values}

The Repository Managed Retention object-type MUST have the following attribute values.

\cmisattributevalue{id}{cmis:rm\_repMgtRetention}

\cmisattributevalue{localName}{<repository-specific>}

\cmisattributevalue{localNamespace}{<repository-specific>}

\cmisattributevalue{queryName}{cmis:rm\_repMgtRetention}

\cmisattributevalue{displayName}{<repository-specific>}

\cmisattributevalue{baseId}{cmis:secondary}

\cmisattributevalue{parentId}{cmis:secondary}

\cmisattributevalue{description}{<repository-specific>}

\cmisattributevalue{creatable}{FALSE}

\cmisattributevalue{fileable}{FALSE}

\cmisattributevalue{queryable}{SHOULD be TRUE}

\cmisattributevalue{controllablePolicy}{FALSE}

\cmisattributevalue{controllableACL}{FALSE}

\cmisattributevalue{includedInSupertypeQuery}{<repository-specific>}

\cmisattributevalue{fulltextIndexed}{<repository-specific>}

\cmisattributevalue{typeMutability.create}{<repository-specific>}

\cmisattributevalue{typeMutability.update}{<repository-specific>}

\cmisattributevalue{typeMutability.delete}{<repository-specific>}


\subparagraph{Property Definitions}

This type has no properties defined by this specification. A repository MAY add repository specific property definitions. 


\subsubsection{Client Managed Retentions}

Client Managed Retentions are used in scenarios where the CMIS client is responsible to calculate the concrete expiration date for a document. This is usually required when documents are related to other objects (like a Business Object in an ERP system) and the documents must get the same retention period than the object where they are related to. In this case a CMIS client can apply a retention period to a document using the Client Managed Retention object-type.

\begin{sloppypar}
If a repository supports Client Managed Retentions, it exposes the secondary type \texttt{cmis:rm\_clientMgtRetention} via the secondary type hierarchy. The CMIS defined secondary type \texttt{cmis:rm\_clientMgtRetention} defines two properties:
\end{sloppypar}
\begin{description}
	\item[cmis:rm\_expirationDate] contains the date until the document must be preserved.
	\item[cmis:rm\_startOfRetention] contains the date from which the retention time was calculated (for documentation purposes only).
\end{description}


A repository MAY define its own secondary types for Client Managed Retentions with additional properties. Those types MUST be derived from the type \texttt{cmis:rm\_clientMgtRetention}.

\begin{sloppypar}


Repositories that support a process to dispose documents after a certain period of time, MAY expose the type \texttt{cmis:rm\_destructionRetention} which is derived from \texttt{cmis:rm\_clientMgtRetention}. This type provides an additional property that defines the date when destruction process SHOULD be triggered:
\end{sloppypar}
\begin{description}
	\item[cmis:rm\_destructionDate] holds the date when the destruction process SHOULD be triggered.
\end{description}

A repository MAY define its own Destruction Retentions. A repository specific Destruction Retention MUST be derived from the type \texttt{cmis:rm\_destructionRetention}.

The repository MAY round up the dates used for expiration and destruction dates according to its internal capabilities.
A secondary type hierarchy for Client Managed Retentions could look like this (white boxes are CMIS defined types, orange boxes are repository specific):

\cmisgraphics{clientmgtretention}{width=1\textwidth}{Client Managed Retentions Types}
%\begin{figure}[htb]
%\centering
%\includegraphics[width=1\textwidth]{clientmgtretention.pdf}
%\caption{Client Managed Retentions Types}
%\end{figure}


\paragraph{Semantics and Rules to be checked for the Expiration Date Property}

The property \texttt{cmis:rm\_expirationDate} either contains a concrete date or (if not known yet) is in the state "not set". In the first case ("specific expiration date"), the affected object MUST NOT be deletable until the specified date (including the specified date). That does NOT imply that the object is being automatically deleted by the storage system after it expired.
In the second case (expiration date "not set"), the affected object MUST NOT be deletable at all.
If a new expiration date is applied to an object, the following rules MUST be obeyed:

\textbf{Assignment rule:}

\begin{enumerate}
	\item A specific expiration date MUST NOT be removable or replaced by an expiration date "not set". The reverse MUST be allowed. That is, it MUST be possible to set a specific expiration date as long as the expiration date is not set.
	\item A new expiration date SHALL only be applicable if the expiration date does not lie in the past. Only an expiration date with a current or a future date MUST be assignable to an object.
\end{enumerate}

\textbf{Prolongation rule:}

\begin{enumerate}
	\item In case an object has already an expiration date assigned, the repository SHALL check whether the new expiration date is equal or greater than the one already assigned. The repository MUST prevent a client from shortening the retention time.
	\item Once a Client Managed Retention has been set (with a specific expiration date or expiration date "not set") the Client Managed Retention MUST NOT be removable, even if the expiration date is expired.
A violation of any aspect of these rules MUST result in a \cmisexceptionlink{constraint} exception. A prolongation of an expiration date MUST succeed regardless of whether the previous expiration date is expired or not.
	\item The destruction date, if set, MUST always be the same as the expiration date or greater than the expiration date. When the retention is prolonged, the destruction date may have to be adjusted as well by the client. The repository SHOULD NOT automatically adjust the destruction date.
\end{enumerate}

Whether a user is allowed to apply a Client Managed Retention or Destruction Retention is repository specific. If the user has no permission to do so, a \cmisexceptionlink{permissionDenied} exception MUST be thrown. In case of others constraints, a \cmisexceptionlink{constraint} exception MUST be thrown.


\paragraph{Client Managed Retention Type}

\subparagraph{Attribute Values}

The Client Managed Retentions object-type MUST have the following attribute values.

\cmisattributevalue{id}{cmis:rm\_clientMgtRetention}

\cmisattributevalue{localName}{<repository-specific>}

\cmisattributevalue{localNamespace}{<repository-specific>}

\cmisattributevalue{queryName}{cmis:rm\_clientMgtRetention}

\cmisattributevalue{displayName}{<repository-specific>}

\cmisattributevalue{baseId}{cmis:secondary}

\cmisattributevalue{parentId}{cmis:secondary}

\cmisattributevalue{description}{<repository-specific>}

\cmisattributevalue{creatable}{FALSE}

\cmisattributevalue{fileable}{FALSE}

\cmisattributevalue{queryable}{SHOULD be TRUE}

\cmisattributevalue{controllablePolicy}{FALSE}

\cmisattributevalue{controllableACL}{FALSE}

\cmisattributevalue{includedInSupertypeQuery}{<repository-specific>}

\cmisattributevalue{fulltextIndexed}{<repository-specific>}

\cmisattributevalue{typeMutability.create}{<repository-specific>}

\cmisattributevalue{typeMutability.update}{<repository-specific>}

\cmisattributevalue{typeMutability.delete}{<repository-specific>}


\subparagraph{Property Definitions}

The Client Managed Retentions object-type MUST have the following property definitions, and MAY include additional property definitions. Any attributes not specified for the property definition are repository specific. The repository MUST have the following property definitions on the Client Managed Retentions object-type:\\

\begin{cmisproperty}{cmis:rm\_expirationDate}{Expiration date.}
	\cmispropertydetail{Property Type}{DateTime}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readwrite}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{<repository-specific>}
\end{cmisproperty}

\begin{cmisproperty}{cmis:rm\_startOfRetention}{Start of retention.}
	\cmispropertydetail{Property Type}{DateTime}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{SHOULD be readwrite}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository-specific>}
	\cmispropertydetail{Orderable}{<repository-specific>}
\end{cmisproperty}


\paragraph {Destruction Retention Type}

\subparagraph{Attribute Values}

The Destruction Retention object-type MUST have the following attribute values.

\cmisattributevalue{id}{cmis:rm\_destructionRetention}

\cmisattributevalue{localName}{<repository-specific>}

\cmisattributevalue{localNamespace}{<repository-specific>}

\cmisattributevalue{queryName}{cmis:rm\_destructionRetention}

\cmisattributevalue{displayName}{<repository-specific>}

\cmisattributevalue{baseId}{cmis:secondary}

\cmisattributevalue{parentId}{cmis:rm\_clientMgtRetention}

\cmisattributevalue{description}{<repository-specific>}

\cmisattributevalue{creatable}{FALSE}

\cmisattributevalue{fileable}{FALSE}

\cmisattributevalue{queryable}{SHOULD be TRUE}

\cmisattributevalue{controllablePolicy}{FALSE}

\cmisattributevalue{controllableACL}{FALSE}

\cmisattributevalue{includedInSupertypeQuery}{<repository-specific>}

\cmisattributevalue{fulltextIndexed}{<repository-specific>}

\cmisattributevalue{typeMutability.create}{<repository-specific>}

\cmisattributevalue{typeMutability.update}{<repository-specific>}

\cmisattributevalue{typeMutability.delete}{<repository-specific>}


\subparagraph{Property Definitions}

The Destruction Retention object-type MUST have the following property definition, inherits all property defintions from \texttt{cmis:rm\_clientMgtRetention}, and MAY include additional property definitions. Any attributes not specified for the property definition are repository specific. The repository MUST have the following property definitions on the Destruction Retentions object-type:\\

\begin{cmisproperty}{cmis:rm\_destructionDate}{Destruction date.}
	\cmispropertydetail{Property Type}{DateTime}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{single}
	\cmispropertydetail{Updatability}{readwrite}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{<repository-specific>}
	\cmispropertydetail{Orderable}{<repository-specific>}
\end{cmisproperty}


\subsubsection{Holds}

A Hold assures that a document can be restored to the state it was in when the hold has been applied (usually by protecting the document from being deleted or modified). Support for other objects than documents is repository specific.

If a repository supports holds, it exposes the secondary type \texttt{cmis:rm\_hold}. This type defines the multi-valued property 
\texttt{cmis:rm\_holdIds} which contains a list of identifiers for the affected litigations or audits.

As long as the property \texttt{cmis:rm\_holdIds} is "not set", the document is not protected by a hold. To protect a document, this property must contain at least one value. The hold type CANNOT be removed from an object as long as the property \texttt{cmis:rm\_holdIds} contains values.

A repository MAY define its own secondary types for holds with additional properties. Those types MUST be derived from \texttt{cmis:rm\_hold}.

A secondary type hierarchy for holds could look like this (white boxes are CMIS defined types, orange boxes are repository specific):

\cmisgraphics{hold}{width=1\textwidth}{Hold Type}
%\begin{figure}[htb]
%\centering
%\includegraphics[width=1\textwidth]{hold.pdf}
%\caption{Hold Types}
%\end{figure}

Whether a user is allowed to apply a hold is repository-specific. If the user has no permission to do so, a \cmisexceptionlink{permissionDenied} exception MUST be thrown. In case of others constraints, a \cmisexceptionlink{constraint} exception MUST be thrown.


\paragraph {Hold Type Definition}


\subparagraph{Attribute Values}

The Hold object-type MUST have the following attribute values.

\cmisattributevalue{id}{cmis:rm\_hold}

\cmisattributevalue{localName}{<repository-specific>}

\cmisattributevalue{localNamespace}{<repository-specific>}

\cmisattributevalue{queryName}{cmis:rm\_hold}

\cmisattributevalue{displayName}{<repository-specific>}

\cmisattributevalue{baseId}{cmis:secondary}

\cmisattributevalue{parentId}{cmis:secondary}

\cmisattributevalue{description}{<repository-specific>}

\cmisattributevalue{creatable}{FALSE}

\cmisattributevalue{fileable}{FALSE}

\cmisattributevalue{queryable}{SHOULD be TRUE}

\cmisattributevalue{controllablePolicy}{FALSE}

\cmisattributevalue{controllableACL}{FALSE}

\cmisattributevalue{includedInSupertypeQuery}{<repository-specific>}

\cmisattributevalue{fulltextIndexed}{<repository-specific>}

\cmisattributevalue{typeMutability.create}{<repository-specific>}

\cmisattributevalue{typeMutability.update}{<repository-specific>}

\cmisattributevalue{typeMutability.delete}{<repository-specific>}


\subparagraph{Property Definitions}

The hold object-type MUST have the following property definitions, and MAY include additional property definition. Any attributes not specified for the property definition are repository specific. The repository MUST have the following property definitions on the hold object-type:\\

\begin{cmisproperty}{cmis:rm\_holdIds}{Hold Identifiers.}
	\cmispropertydetail{Property Type}{String}
	\cmispropertydetail{Inherited}{FALSE}
	\cmispropertydetail{Required}{FALSE}
	\cmispropertydetail{Cardinality}{multi}
	\cmispropertydetail{Updatability}{SHOULD be readwrite}
	\cmispropertydetail{Choices}{Not Applicable}
	\cmispropertydetail{Open Choice}{Not Applicable}
	\cmispropertydetail{Queryable}{SHOULD be TRUE}
	\cmispropertydetail{Orderable}{FALSE}
\end{cmisproperty}