The Content Management Interoperability Services (CMIS)
standard defines a domain model and set of bindings that include Web Services
and ReSTful AtomPub that can be used by applications to work with one or more
Content Management repositories/systems.
The CMIS interface is designed to be layered on top of
existing Content Management systems and their existing programmatic interfaces.
It is not intended to prescribe how specific features should be implemented
within those CM systems, nor to exhaustively expose all of the CM system's
capabilities through the CMIS interfaces. Rather, it is intended to define a
generic/universal set of capabilities provided by a CM system and a set of
services for working with those capabilities.
The key words "MUST, ",
"MUST NOT, ", "REQUIRED, ",
"SHALL, ", "SHALL
NOT, ", "SHOULD, ",
"SHOULD NOT, ", "RECOMMENDED, ",
"MAY,",
and "OPTIONAL"
in this document are to be interpreted as described in RFC2119.
[RFC4287] M. Nottingham, R. Sayre, Atom Syndication Format, http://www.ietf.org/rfc/rfc4287.txt, December 2005
[RFC5023] J. Gregorio, B. de hOra, Atom Publishing Protocol,
http://www.ietf.org/rfc/rfc5023.txt,
October 2007
[RFC2616] R. Fielding, J. Gettys, J.
Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, Hypertext Transfer
Protocol --HTTP/1.1, http://www.ietf.org/rfc/rfc2616.txt,
June 1999
[RFC2119] S. Bradner, Key
words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt,
March 1997
[RFC4918] L. Dusseault, HTTP Extensions
for Web Distributed Authoring and Versioning (WebDAV), June 2007
[RFC3986] T. Berners-Lee, R. Fielding, L. Masinter,
Unified Resource Identifier, January 2005
[ID-Brown] J. Reschke Editor, A. Brown, G.
Clemm, Link Relation
Types for Simple Version Navigation between Web Resources, http://www.ietf.org/id/draft-brown-versioning-link-relations-07.txthttp://www.ietf.org/id/draft-brown-versioning-link-relations-08.txt,
2010
[ID-WebLinking] M. Nottingham, Web Linking, http://tools.ietf.org/id/draft-nottingham-http-link-header-07.txthttp://tools.ietf.org/id/draft-nottingham-http-link-header-08.txt,
2010
CMIS provides an interface for an
application to access a 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 "Get
Repositories"
service (getRepositories) to obtain a list of repositories that are
available at that endpoint. The Repository Identity MUST uniquely identify an
available repository at this service endpoint. Both the repository name and the
repository identity are opaque to CMIS. Aside from the "Get
Repositories"
service, all other CMIS services are single-repository-scoped, and require a
Repository Identity as an input parameter. In other words, except for the "Get
Repositories"
service, multi-repository and inter-repository operations are not supported by
CMIS.
The repository itself is described by the CMIS "Get
Repository Information"
service. The service output is fully described in section 2.2.2.2 getRepositoryInfo.
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 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.
Navigation Capabilities:
capabilityGetDescendants
Ability for an application to
enumerate the descendants of a folder via the getDescendants service.
See
section: 2.2.3.2 getDescendants
capabilityGetFolderTree
Ability for an application to retrieve
the folder tree via the getFolderTree service.
See
section: 2.2.3.3 getFolderTree
Object Capabilities:
capabilityContentStreamUpdatability (enumCapabilityContentStreamUpdates)
Indicates the support a repository
has for updating a document's
content stream. Valid values are:
· none: The content stream may never
be updated.
· anytime: The content stream
may be updated any time.
pwconly: The
content stream may be updated only when checked out. The abbreviation PWC is
described in section 0
· Versioning.
See Section: 2.1.4.1 Content Stream
capabilityChanges (enumCapabilityChanges)
Indicates what level of
changes (if any) the repository exposes via the "change
log"
service. Valid values are:
· none:
The repository does not support the change log feature.
· objectidsonly: The change log can return only the
ObjectIDs for changed objects in the repository and an indication of the type
of change, not details of the actual change.
· properties: The change log can
return properties and the ObjectID for the changed objects
· all: The change log can return the
ObjectIDs for changed objects in the repository and more information about the
actual change
See Section: 2.1.11 Change Log
capabilityRenditions (enumCapabilityRendition)
Indicates whether or not
the repository exposes renditions of document or folder objects.
· none:
The repository does not expose renditions at all.
· read:
Renditions are provided by the repository and readable by the client.
Filing Capabilities:
capabilityMultifiling
Ability for an application to
file a document or other file-able object in more than one folder
See Section: 2.1.5 Folder Object
capabilityUnfiling
Ability for an application to
leave a document or other file-able object not filed in any folder
See Section: 2.1.5 Folder Object
capabilityVersionSpecificFiling
Ability for an application to
file individual versions (i.e., not all versions) of a document in a folder
See Section: 0
Versioning
Versioning Capabilities:
capabilityPWCUpdatable
Ability for an application to
update the "Private
Working Copy" of
a checked-out document
See Section: 0
Versioning
capabilityPWCSearchable
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: 0
Versioning
capabilityAllVersionsSearchable
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: 0
Versioning
Query Capabilities:
capabilityQuery (enumCapabilityQuery)
Indicates the types of queries that
the Repository has the ability to fulfill. Query support levels are:
· none: No queries of any kind can
be fulfilled.
· metadataonly: Only queries that
filter based on object properties can be fulfilled. Specifically, the
CONTAINS() predicate function is not supported.
· 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.
· 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.
· bothcombined: The repository can
fulfill queries that filter on both the full-text content of documents and
their properties in the same query.
See Section: 2.1.10 Query
capabilityJoin (enumCapabilityJoin)
Indicates
the types of JOIN keywords that the Repository can fulfill in queries. Support
levels are:
· none: The repository cannot
fulfill any queries that include any JOIN clauses.
· inneronly: The repository can
fulfill queries that include an INNER JOIN clause, but cannot fulfill queries
that include other types of JOIN clauses.
· innerandouter: The repository can
fulfill queries that include any type of JOIN clause defined by the CMIS query
grammar.
See Section: 2.1.10 Query
ACL Capabilities:
capabilityACL (enumCapabilityACL)
Indicates the level of support
for ACLs by the repository
· none: The repository does not
support ACL services
· discover: The repository supports
discovery of ACLs (getACL and other services)
· manage: The repository supports
discovery of ACLs AND applying ACLs (getACL and applyACL services)
See Section: 2.8 Access Control
2.1.1.2 Implementation Information
The "Get
Repository Information"
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 2.1.5.2 Folder Hierarchy), and MAY include other
implementation-specific information. The version of CMIS that the repository
supports MUST be expressed as a Decimal that matches the specification version.
The entities managed by CMIS are
modeled as typed Objects. There are four base types of objects: Document
Objects, Folder Objects, Relationship Objects,
and Policy Objects.
- A
document object represents a standalone information asset. Document
objects are the elementary entities managed by a CMIS repository.
- A
folder object represents a logical container for a collection of
"file-able"
objects, which include folder objects and document 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.object-type
definition.
- A
relationship object represents an instance of directional
relationship between two objects. The support for relationship objects is
optional, and may be discovered via the
"Get
Type Children"
service.
- A
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, and
may be discovered via the "Get
Type Children"
service.
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.
However, object-type management services, such as the creation, modification,
and deletion of an object-type, are outside the scope of CMIS.
Every CMIS object has an opaque
and immutable Object Identity (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, 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.
In addition, a document object MAY
have a 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 Renditions associated with it. A rendition can be a
thumbnail or an alternate representation of the content stream.
Document or folder objects MAY
have one Access Control List (ACL), which controls access to the
document or folder. A policy object may also control access to the document or
folder. An ACL represents a list of 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.
2.1.2.1 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 MAY be preserved by the repository.
If a value is not
provided for aA property, the property is in a value
not set state. There is no null value for a property. Through protocol
binding, a property is 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, or is set to a
particular" state, its property value orMUST
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"
(W3C Recommendation, 28 October 2004, http://www.w3.org/TR/xmlschema-2/):
- string (xsd:string)
- boolean (xsd:boolean)
- decimal (see section 2.1.3.3.5 Attributes specific to Decimal Object-Type Property Definitions)
- integer (xsd:integer)
- datetime (xsd:dateTime and see
section 2.1.3.3.5 Attributes specific to Decimal Object-Type Property
Definitions)
- uri (xsd:anyURI)
In addition, the following Property-Types are also specified
by CMIS:
Individual protocol bindings MAY
override or re-specify these property types.
All properties MUST supply a String 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:
- whitespace
,"
",
- comma
,","
- double quotes
'"'
- single quotes
"'"
- backslash
\"\"
- the period
."."
character or,
- the open
("("
or close )")"
parenthesis characters.
2.1.2.1.1 ID Property
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 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 an 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
exception and suggest a remedial action. The content of such messages is
outside the scope of CMIS.
2.1.2.1.2 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.
2.1.3 Object-Type
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 Object-Type
Identifier, which is of type ID.
A CMIS repository MUST expose
exactly one collection of Object-Types via the "Repository"
services (getTypeChildren, getTypeDescendants, getTypeDefinition).
While a repository MAY define
additional object-types beyond the CMIS
Base Object-Types,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.
Hierarchy and Inheritance
for Object-Types are supported by CMIS in the following manner:
- A CMIS
repository MUST have these base types:
o
cmis:document:document
object-type
o
cmis:folder:folder
object-type
- A CMIS
repository MAY have these base types:
o
cmis:relationship:relationship
object-type
o
cmis:policycmis:policy
object-type
- Additional base
types MUST NOT exist. Additional object-types MAY be defined as sub-types
or descendant types of these four base types.
- A Base
Type does not have a parent type.
- A non-base type
has one and only one parent type. An object-type
's
Parent Type is a part of the object-type definition.
- An object-type
definition includes a set of
object-type
attributesobject-type
attributes (e.g. Fileable, Queryable, etc.) and a property
schema that will apply to Objects of that type.
o
There is no inheritance of object-type attributes from a parent
object-type to its sub-types.
- The properties of
a CMIS base type MUST be inherited by its descendant types.
- A 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.
o
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.
- The scope of a
query on a given object-type is automatically expanded to include all the Descendant
Types of the given object-type with the attribute 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.
o
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 NULL value for all
objects of this type. (See section 2.1.10 Query.)
2.1.3.2.1 Attributes common to ALL Object-Type Definitions
All Object-Type Definitions
MUST contain the following attributes:
id ID
This opaque attribute identifies
this object-type in the repository.
localName String
(optional)
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.
Two properties with the same
localName and localNamespace MUST have the same semantic equality.
localNamespace String
(optional)
This attribute allows repositories
to represent the internal namespace of the underlying repository's
name for the object-type.
queryName String
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:
- whitespace
,"
",
- comma
,","
- double quotes
'"'
- single quotes
"'"
- backslash
\"\"
- the period
."."
character or,
- the open
("("
or close )")"
parenthesis characters.
displayName String
(optional)
Used for presentation by
application.
baseId Enum
A value that
indicates whether the base type for this Object-Type is the Document, Folder,
Relationship, or Policy base type.
parentId ID
The ID of the Object-Type's
immediate parent type.
It MUST be "not
set"
for a base type.
description String
(optional)
Description
of this object-type, such as the nature of content, or its intended use. Used
for presentation by application.
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.
fileable Boolean
Indicates whether or not objects of
this type are file-able.file-able.
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.
controllablePolicy Boolean
Indicates whether or not objects of
this type are controllable via policies. Policy objects can only be applied to
controllablePolicy objects.
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.
fulltextIndexed Boolean
Indicates whether objects of this
type are indexed for full-text search for querying via the CONTAINS() query
predicate.
includedInSupertypeQuery Boolean
Indicates whether this type and its
subtypes appear in a query of this type's
ancestor types.
For example: if Invoice is a sub-type
of cmis:document, if this is TRUE on Invoice then for a query on cmis:document,
instances of Invoice will be returned if they match.
If this attribute is FALSE, no
instances of Invoice will be returned even if they match the query.
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.
2.1.3.3.1 Property Types
Property types are
defined in section 2.1.2.1 Property.
2.1.3.3.2 Attributes common to ALL Object-Type Property Definitions
All Object-Type Property
Definitions MUST contain the following attributes:
id ID
This opaque attribute uniquely
identifies the property in the repository. If two Object-Types each contain
property definitions with the same ID, those property definitions are the same.
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.
localNamespace String (optional)
This attribute allows repositories
to represent the internal namespace of the underlying repository's
name for the property.
queryName String
Used for query
operations on properties. This is an opaque String with limitations. Please
see queryName in Object-Type
Attributes for the limitations on what characters are not allowed.
displayName String (optional)
Used for presentation by
application.
description String (optional)
This is an optional attribute
containing a description of the property
propertyType Enum
This
attribute indicates the type of this property. It MUST be one of the allowed
property types. (See section 2.1.2.1 Property.)
cardinality Enum
Indicates whether the property can
have "zero
or one" or
"zero
or more"
values.
Values:
· single: Property can have zero or
one values (if property is not required), or exactly one value (if property is
required)
· multi: Property can have zero or
more values (if property is not required), or one or more values (if property
is required).
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 operations SHOULD be the
same as the order in which they were supplied during previous create/update
operation.
updatability Enum
Indicates under what circumstances
the value of this property MAY be updated.
Values:
· 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.
o The value
of a readOnly property MAY be indirectly modified by other repository
interactions (for example, calling "updateProperties"
on an object will change the object's
last modified date, even though that property cannot be directly set via an
updateProperties() service call.)
·
readwrite: The
property value can be modified using the updateProperties service.
·
whencheckedout:
The property value MUST only be update-able using a private working copy"private
working copy" Document.
o I.e. the
update is either made on a "private
working copy"
object or made using a "check
in"
service.
·
oncreate: The
property value MUST only be update-able during the Create operation on that
Object.
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.
required Boolean
This
attribute is only applicable to non-sytem 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 an 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
cmis:objectId, cmis:createdBy) MUST be set by the repository. However, the
property's "required"
attribute SHOULD be FALSE because it is read-only to applications.
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.
orderable Boolean
Indicates whether the property
can appear in the ORDER BY clause of a CMIS query statement or an ORDERBY
parameter.
This property MUST be FALSE for any
property whose cardinality is "multi.".
choices <PropertyChoiceType
list> (multi-valued)
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:
o Europe:
§ England
§ France
§ Germany
o North America
§ Canada
§ USA
§ Mexico
openChoice Boolean
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.
defaultValue <PropertyType>
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 "value
not set"
state for the 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.
2.1.3.3.3 Attributes specific to Integer Object-Type Property Definitions
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.
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 constraint exception.
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 constraint exception.
2.1.3.3.4 Attributes specific to DateTime Object-Type Property Definitions
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.
resolution String Enumeration
This is the precision in bits
supported for values of this property. Valid values for this attribute are:
· Year:
Year resolution is persisted
· Date:
Date resolution is persisted
· Time:
Time resolution is persisted
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.
precision Integer Enumeration
This is the precision in bits
supported for values of this property. Valid values for this attribute are:
· 32:
32-bit precision (("single"
as specified in IEEE-754-1985).
· 64:
64-bit precision (("double"
as specified in IEEE-754-1985.)
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 constraint
exception.
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 constraint exception.
2.1.3.3.6 Attributes specific to String Object-Type Property Definitions
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.
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 larger than the specified maximum
length, the repository MUST throw a constraint
exception.
Document objects are the
elementary information entities managed by the repository.
Depending on its Object-type
definition, a Document Object may be:
- Version-able: Can be acted upon via the
Versioning Services (for example:
checkOut, checkIn).checkOut,
checkIn).
- File-able: Can be filed in zero, one, or more
than one folder via the Multi-filing services.
- Query-able: Can be located via the Discovery
Services (query).
- Controllable-Policy: Can have Policies applied
to it (see section 2.1.7 Policy Object.)
- Controllable-ACL: Can have an ACL applied to it
(see section 2.8 Access Control)
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.
A content-stream is a binary
stream. Its maximum length is repository-specific. Each content-stream has a MIME
Media Type, as defined by RFC2045 and 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 services
for content-stream, using the ID of a content-stream's
containing document object for identification. A content stream also has a
streamId which is used for access to the stream. The "Set
Content-Stream"
service (setContentStream) either creates a new content-stream for a
document object or replaces an existing content-stream. The "Get
Content-Stream"
service (getContentStream) retrieves a content-stream. The "Delete
Content-Stream"
service (deleteContentStream) deletes a content-stream from a document object.
In addition, the "CreateDocument"
and "Check-in"
services MAY also take a content-stream as an optional input. A content stream
MUST be specified if required by the type definition. These are the only
services that operate on content-stream. The "Get
Properties"
and "Query"
services, for example, do not return a content-stream.
"Set
Content-Stream"
and "Delete
Content-Stream"
services are considered modifications to a content-stream's
containing document object, and SHOULD therefore change the object's
LastModificationDate property upon successful completion.
The ability to set or delete a
content stream is controlled by the capabilityContentStreamUpdatability
capability.
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 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 getRenditions service. A rendition stream can be
retrieved using the getContentStream service with the rendition's
streamId parameter.
2.1.4.2.1 Rendition Attributes
A rendition has the following attributes:
streamId ID
Identifies the rendition stream.
mimeType String
The MIME type of the rendition
stream.
length Integer
(optional)
The length of the rendition stream
in bytes.
title String
(optional)
Human readable
information about the rendition.
kind String
A categorization
String associated with the rendition.
height Integer
(optional)
Typically used
for 'image'
renditions (expressed as pixels). SHOULD be present if kind = cmis:thumbnail.
width Integer
(optional)
Typically used for 'image'
renditions (expressed as pixels). SHOULD be present if kind = cmis:thumbnail.
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.
2.1.4.2.2 Rendition Kind
A Rendition may be categorized via its kind. The repository is responsible
for assigning kinds to Renditions, including custom kinds. A repository kind
does not necessarily identify a single Rendition for a given Object.
CMIS defines the following kind:
·
cmis:thumbnail
: A rendition whose purpose is
to a provide an image preview of the document without requiring the client to
download the full document content stream. Thumbnails are generally reduced
fidelity representations.
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.
2.1.4.3.1 Attributes specific to Document Object-Types
The following Object attributes MUST only
apply to Object-Type definitions whose baseId is the cmis:document Object-Type,
in addition to the common attributes specified above:
versionable Boolean
Indicates whether or not objects of
this type are version-able. (See section 0
Versioning.)
contentStreamAllowed Enum
A
value that indicates whether a content-stream MAY, MUST, or MUST NOT be
included in objects of this type. Values:
· notallowed: A
content-stream MUST NOT be included
· allowed: A content-stream
MAY be included
· required: A content-stream MUST
be included (i.e. MUST be included when the object is created, and MUST NOT be
deleted.)
2.1.4.3.2 Attribute Values
The Document Object-Type MUST have the following attribute
values.
Notes:
·
A value of <repository-specific> indicates that the value
of the property MAY be set to any valid value for the attribute type.
·
Unless explicitly stated otherwise, all values specified in the
list MUST be followed for the Object-Type definition.
id
Value: cmis:document
localName
Value: <repository-specific>
localNamespace
Value: <repository-specific>
queryName
Value: cmis:document
displayName
Value: <repository-specific>
baseId
Value: cmis:document
parentId
Value: Not set
description
Value: <repository-specific>
creatable
Value: <repository-specific>
fileable
Value: TRUE
queryable
Value: SHOULD be TRUE
controllablePolicy
Value: <repository-specific>
includedInSupertypeQuery
Value: <repository-specific>
versionable
Value: <repository-specific>
contentStreamAllowed
Value: <repository-specific>
controllableACL
Value: <repository-specific>
fulltextIndexed
Value: <repository-specific>
2.1.4.3.3 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 Type:
cmis:name Name
of the object
Inherited: False
Property Type: String
Cardinality: Single
cmis:objectId Id
of the object
Required: False
Inherited: False
Property Type: ID
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:baseTypeId Id
of the base object-type for the object
Required: False
Inherited: False
Property Type: ID
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:objectTypeId Id
of the object's type
Required: True
Inherited: False
Property Type: ID
Cardinality: Single
Updatability: oncreate
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository
MUST return this property with non-empty values when an object is requested and
the property filter does not exclude them
cmis:createdBy User
who created the object.
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Queryable: True
Orderable: True
Repository
MUST return this property with non-empty values when an object is requested and
the property filter does not exclude them
cmis:creationDate DateTime
when the object was created.
Required: False
Inherited: False
Property Type: DateTime
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Queryable: True
Orderable: True
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:lastModifiedBy User
who last modified the object.
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Queryable: True
Orderable: True
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:lastModificationDate DateTime
when the object was last modified.
Required: False
Inherited: False
Property Type: DateTime
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Queryable: True
Orderable: True
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:changeToken Opaque
token used for optimistic locking & concurrency checking. (see section 2.2.1.3 Change Tokens)
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this
property with non-empty values when an object is requested and the property
filter does not exclude them. If the repository does not support change tokens,
this property SHOULD not be set.
cmis:isImmutable TRUE
if the repository MUST throw an error at any attempt to update or delete the
object.
Required: False
Inherited: False
Property Type: Boolean
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:isLatestVersion See section 0
Versioning.
Required: False
Inherited: False
Property Type: Boolean
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them. Version Property Values are repository-specific when a document
is defined as non-versionable.
cmis:isMajorVersion See section 0
Versioning.
Required: False
Inherited: False
Property Type: Boolean
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them. Version Property Values are repository-specific when a
document is defined as non-versionable.
cmis:isLatestMajorVersion See section 0
Versioning.
Required: False
Inherited: False
Property Type: Boolean
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them. Version Property Values are repository-specific when a
document is defined as non-versionable.
cmis:versionLabel See section 0
Versioning.
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them. Version Property Values are repository-specific when a
document is defined as non-versionable.
cmis:versionSeriesId See section 0
Versioning.
Required: False
Inherited: False
Property Type: ID
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them. Version Property Values are repository-specific when a
document is defined as non-versionable.
cmis:isVersionSeriesCheckedOut See section 0
Versioning.
Required: False
Inherited: False
Property Type: Boolean
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them. Version Property Values are repository-specific when a
document is defined as non-versionable.
cmis:versionSeriesCheckedOutBy See section 0
Versioning.
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Version
Property Values are repository-specific when a document is defined as
non-versionable.
cmis:versionSeriesCheckedOutId See section 0
Versioning.
Required: False
Inherited: False
Property Type: ID
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Version
Property Values are repository-specific when a document is defined as
non-versionable.
cmis:checkinComment See section 0
Versioning.
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Version Property Values are repository-specific
when a document is defined as non-versionable.
cmis:contentStreamLength Length
of the content stream (in bytes).
Required: False
Inherited: False
Property Type: Integer
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them and if the document has a content stream
cmis:contentStreamMimeType MIME
type of the Content Stream
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them and if the document has a content stream
cmis:contentStreamFileName File
name of the Content Stream
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them and if the document has a content stream
cmis:contentStreamId Id
of the stream
Required: False
Inherited: False
Property Type: ID
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
2.1.5 Folder Object
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 Parent object and each object in the
collection being a 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 2.1.6 Relationship Object.)
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 2.1.4.2 Renditions).
2.1.5.1 File-able
Objects
A 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:
cmis:folder
MUST be file-able
cmis:document
MUST be file-able
cmis:relationship
MUST NOT be file-able
cmis:policy
MAY be file-able
2.1.5.1.1 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 "Get
Repository Information"
service (getRepositoryInfo).
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 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 IN_FOLDER() and IN_TREE() function calls in
a query. For non-versionable fileable objects, their membership in a folder
does not have version sensitivity.
2.1.5.1.2 Filing Restrictions by Object-Type
A folder collection's
membership MAY be restricted by object-type. Each folder object has a
multi-valued 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 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.
2.1.5.2 Folder Hierarchy
CMIS imposes the following
constraints on folder objects:
·
Every folder object, except for one which is called the Root
Folder, MUST have one and only one parent folder. The Root Folder does
not have a parent.
- A
cycle in folder containment relationships is not allowed. That is, a
folder object cannot have itself as one of its descendant objects.
- A
child object that is a folder object can itself be the parent object of
other file-able objects.
With these constraints, the folder
objects in a CMIS repository necessarily form a strict hierarchy, with the 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 Descendant
objects of the given folder objectA folder object together with all its
descendant objects are collectively called a Tree rooted at that
folder object.
A non-folder object does not have
any descendant object. Thus, a 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.
Folder objects are handled using the basic CRUD services for objects,the
basic CRUD services for objects, and the folder graph is traversed
using the Navigation Services.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.
A folder hierarchy MAY be represented in a canonical
notation such as path. For CMIS, a path is represented by:
/'/'
for the root folder- All
paths start with the root folder.
- A
set of the folder and object path segments separated by
/'/'
in order of closest to the root.
- Folder
and object path segments are specified by pathSegment tokens which can be
retrieved by all services that take an includePathSegments
parameter.
- A
pathSegment token MUST not include a
/'/'
character.
- It
is repository specific how a repository chooses the value for
pathSegment. Repositories might choose to use cmis:name or content
stream filename for pathSegment token.
- The
pathSegment token for each item MUST uniquely identify the item in the
folder.
E.g., if folder A is under the root, and folder B is under
A, then the path would be /A/B.
A path for an object may be calculated by taking the item's
parent folder cmis:path property and appending the /"/"
character and the object's
pathSegment. This constructed path may be given as input to the getObjectByPath
service for object by path retrieval.
The getObjectParents service returns relativePathSegment tokens. These
tokens are the pathSegment of the input object relative to the parent folders.
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.
2.1.5.4.1 Attribute Values
The Folder Object-Type MUST have the following attribute
values.
Notes:
·
A value of <repository-specific> indicates that the value
of the property MAY be set to any valid value for the attribute type.
·
Unless explicitly stated otherwise, all values specified in the
table MUST be followed for the Object-Type definition.
id
Value: cmis:folder
localName
Value: <repository-specific>
localNamespace
Value: <repository-specific>
queryName
Value: cmis:folder
displayName
Value: <repository-specific>
baseId
Value: cmis:folder
parentId
Value: Not set
description
Value: <repository-specific>
creatable
Value: <repository-specific>
fileable
Value: TRUE
queryable
Value: SHOULD be
TRUE
controllablePolicy
Value: <repository-specific>
includedInSupertypeQuery
Value: <repository-specific>
controllableACL
Value: <repository-specific>
fulltextIndexed
Value: <repository-specific>
2.1.5.4.2 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 Type:
cmis:name Name
of the object
Inherited: False
Property Type: String
Cardinality: Single
Required: True
cmis:objectId Id
of the object
Required: False
Inherited: False
Property Type: ID
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:baseTypeId Id
of the base object-type for the object
Required: False
Inherited: False
Property Type: ID
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:objectTypeId Id
of the object's type
Required: FalseTrue
Inherited: False
Property Type: ID
Cardinality: Single
Updatability: oncreate
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:createdBy User
who created the object.
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Queryable: True
Orderable: True
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:creationDate DateTime
when the object was created.
Required: False
Inherited: False
Property Type: DateTime
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Queryable: True
Orderable: True
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:lastModifiedBy User
who last modified the object.
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Queryable: True
Orderable: True
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:lastModificationDate DateTime
when the object was last modified.
Required: False
Inherited: False
Property Type: DateTime
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Queryable: True
Orderable: True
MUST be set on the object
cmis:changeToken Token
used for optimistic locking & concurrency checking. (see section 2.2.1.3 Change Tokens)
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this
property with non-empty values when an object is requested and the property
filter does not exclude them. If the repository does not support change tokens,
this property SHOULD not be set.
cmis:parentId ID
of the parent folder of the folder.
Required: False
Inherited: False
Property Type: ID
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:path The
fully qualified path to this folder. See section 2.1.5.3 Paths.
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:allowedChildObjectTypeIds Id's
of the set of Object-types that can be created, moved or filed into this
folder.
Required: False
Inherited: False
Property Type: ID
Cardinality: Multi
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
2.1.6 Relationship Object
A relationship object is
semantically a 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 "Get
Types"
service call.
A Relationship Object
instantiates an explicit, binary, directional, non-invasive, and typed relationship
between a Source Object and a Target Object. The
source object and the target object MUST both be independent objects, such as a
document object, a folder object, or a policy 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 "Get
Relationships"
service (getObjectRelationships) 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).
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.
2.1.6.1.1 Attributes specific to Relationship Object-Types
The following Object attributes MUST only
apply to Object-Type definitions whose baseId is the cmis:relationship
Object-Type, in addition to the common attributes specified above:
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.
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.
2.1.6.1.2 Attribute Values
The Relationship Object-Type MUST have the following
attribute values.
Notes:
·
A value of <repository-specific> indicates that the value
of the property MAY be set to any valid value for the attribute type.
·
Unless explicitly stated otherwise, all values specified in the
table MUST be followed for the Object-Type definition.
id
Value: cmis:relationship
localName
Value: <repository-specific>
localNamespace
Value: <repository-specific>
queryName
Value: cmis:relationship
displayName
Value: <repository-specific>
baseId
Value: cmis:relationship
parentId
Value: Not set
description
Value: <repository-specific>
creatable
Value: <repository-specific>
fileable
Value: FALSE
queryable
Value: <repository-specific>
includedInSupertypeQuery
Value: <repository-specific>
controllablePolicy
Value: <repository-specific>
allowedSourceTypes
Value: <repository-specific>
allowedTargetTypes
Value: <repository-specific>
controllableACL
Value: <repository-specific>
fulltextIndexed
Value: <repository-specific>
2.1.6.1.3 Property Definitions
The Relationship base Object-Type MUST have the following
property definitions, and MAY include additional property definitions. Any
attributes not specified by the Property Definitions 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 Type:
cmis:name Name
of the object
Inherited: False
Property Type: String
Cardinality: Single
cmis:objectId Id
of the object
Required: False
Inherited: False
Property Type: ID
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:baseTypeId Id
of the base object-type for the object
Required: False
Inherited: False
Property Type: ID
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:objectTypeId Id
of the object's type
Required: FalseTrue
Inherited: False
Property Type: ID
Cardinality: Single
Updatability: oncreate
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:createdBy User
who created the object.
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:creationDate DateTime
when the object was created.
Required: False
Inherited: False
Property Type: DateTime
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:lastModifiedBy User
who last modified the object.
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:lastModificationDate DateTime
when the object was last modified.
Required: False
Inherited: False
Property Type: DateTime
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return this property
with non-empty values when an object is requested and the property filter does
not exclude them
cmis:changeToken Opaque
token used for optimistic locking & concurrency checking. (see section 2.2.1.3 Change Tokens)
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return
this property with non-empty values when an object is requested and the
property filter does not exclude them. If the repository does not support
change tokens, this property SHOULD not be set.
cmis:sourceId ID
of the source object of the relationship.
Required: True
Inherited: False
Property Type: ID
Cardinality: Single
Choices: Not
Applicable
Open Choice: Not
Applicable
cmis:targetId ID
of the target object of the relationship.
Required: True
Inherited: False
Property Type: ID
Cardinality: Single
Choices: Not
Applicable
Open Choice: Not
Applicable
2.1.7 Policy Object
A policy object represents an
administrative policy that can be enforced by a repository, such as a retention
management policy. CMIS 1.0 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 "Get
Types"
service call. This is an extension point for repositories that want to expose
other capabilities via CMIS that are not supported directly in CMIS 1.0.
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 1.0. Indirectly applying policy to an object, e.g. through inheritance, is
outside the scope of CMIS 1.0.
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 "Apply
Policy" (applyPolicy)
and the "Remove
Policy" (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 "Get
Applied Policies" (getAppliedPolicies)
service may be used to obtain the policy objects that are currently applied to
a controllable object.
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.
2.1.7.1.1 Attribute Values
The Policy Object-Type MUST have the following attribute
values.
Notes:
·
A value of <repository-specific> indicates that the value
of the property MAY be set to any valid value for the attribute type.
·
Unless explicitly stated otherwise, all values specified in the
table MUST be followed for the Object-Type definition.
id
Value: cmis:policy
localName
Value: <repository-specific>
localNamespace
Value: <repository-specific>
queryName
Value: cmis:policy
displayName
Value: <repository-specific>
baseId
Value: cmis:policy
parentId
Value: Not set
description
Value: <repository-specific>
creatable
Value: <repository-specific>
fileable
Value: <repository-specific>
queryable
Value: <repository-specific>
includedInSupertypeQuery
Value: <repository-specific>
controllablePolicy
Value: <repository-specific>
controllableACL
Value: <repository-specific>
fulltextIndexed
Value: <repository-specific>
2.1.7.1.2 Property Definitions
The Policy base Object-Type MUST have the following property
definitions, and MAY include additional property definitions. Any attributes
not specified by the Property Definitions 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 Type:
cmis:name Name
of the object
Inherited: False
Property Type: String
Cardinality: Single
cmis:objectId Id
of the object
Required: False
Inherited: False
Property Type: ID
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
cmis:baseTypeId Id
of the base object-type for the object
Required: False
Inherited: False
Property Type: ID
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
cmis:objectTypeId Id
of the object's type
Required: FalseTrue
Inherited: False
Property Type: ID
Cardinality: Single
Updatability: oncreate
Choices: Not
Applicable
Open Choice: Not
Applicable
cmis:createdBy User
who created the object.
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
cmis:creationDate DateTime
when the object was created.
Required: False
Inherited: False
Property Type: DateTime
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
cmis:lastModifiedBy User
who last modified the object.
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
cmis:lastModificationDate DateTime
when the object was last modified.
Required: False
Inherited: False
Property Type: DateTime
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
cmis:changeToken Opaque
token used for optimistic locking & concurrency checking. (see section 2.2.1.3 Change Tokens)
Required: False
Inherited: False
Property Type: String
Cardinality: Single
Updatability: Read
Only
Choices: Not
Applicable
Open Choice: Not
Applicable
Repository MUST return
this property with non-empty values when an object is requested and the
property filter does not exclude them. If the repository does not support
change tokens, this property SHOULD not be set.
cmis:policyText User-friendly
description of the policy
Required: True
Inherited: False
Property Type: String
Cardinality: Single
Choices: Not
Applicable
Open Choice: Not
Applicable
2.1.8 Access Control
A repository can support either a
base set of CMIS-defined permissions and/or its own set of repository specific
permissions.
The 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 applyACL service permits either CMIS permissions or
repository permissions, or a combination of both, to be used.
An ACL is a list of 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:
- one
Principal: A principal represents a user management object,
e.g. a user, group, or role.
It holds one String with the principalid.
- One
or more Strings with the names of the permissions.
- a
Boolean flag direct, which indicates if TRUE the ACE
is directly assigned to the object. If FALSE, that the ACE is somehow
derived.
There are three basic permissions predefined by CMIS:
·
cmis:read: to be used to express "permission
to read.". A
Repository SHOULD express the permission for reading properties AND reading
content with this permission.
·
cmis:write: to be used to express "permission
to write.".
SHOULD be used to express permission to write properties and content of an
object. MAY include other basic CMIS permissions.
·
cmis:all: SHOULD be used to express all the permissions of
a repository. SHOULD include all other basic CMIS permissions.
How these basic permissions can be
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 getRepositoryInfo
(see below).
Repositories MAY extend this set with repository-specific
permissions.
Whether a repository supports ACLs at all, may be discovered
via capabilityACL returned by getRepositoryInfo (see section 2.1.1.1 Optional Capabilities). If capabilityACL is none, ACLs are not supported by the repository.
If capabilityACL is discover
or manage, additional
information about the repositories permission model and how changes to ACL are
handled, can be discovered via the getRepositoryInfo service:
·
<Array> Enum propagation:
specifies, how non-direct ACEs can be handled by the repository using the
following values (see section 2.2.10.2 applyACL):
o
objectonly indicates, that the repository is able to apply
ACEs to a document or folder, without changing the ACLs of other objects.
o
propagate: indicates that the ACEs is to be applied to the
given object and all inheriting objects. Propagate incorporates
the support for objectonly.
o
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.
·
<Array> PermissionDefinition repositoryPermissions: is
a list with names and descriptions of the supported permissions.
·
<Array> PermissionMapping mappings: contains
a list with mappings for the basic CMIS permissions to allowed actions.
2.1.8.3.1 Supported Permissions
The list of permission definitions
returned by getRepositoryInfo lists all the permissions a
repository supports. This list also includes the CMIS permissions if supported
by the repository.
A PermissionDefinition holds:
- String
permission: the (technical) name of the permission (unique within the
list of permission definitions).
- (Optional)
String description: an optional description of the permission that
should be used as the permission
's
name to be presented to the user.
CMIS provides a mechanism called "AllowableActions"
which allows an application to discover the set of service operations that can
currently be performed on a particular object, 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:
- Constraints
inherent in the CMIS Domain Model based on the object
's
base type or current versioning state.
- Policies
or other control mechanisms that are opaque to CMIS.
CMIS defines several services that applications can use at
run-time to discover the AllowableActions 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 above.
This section defines both the allowable actions as well as
how those actions are presented in the PermissionMapping table.
The Permission Mapping table contains a set of (key, permissions)
pairs:
o
String Key: Because several allowable actions may require
permissions on more than one object for example, moving a document from one
folder to another may require permissions on the document and each of the
folders the mapping table is defined in terms of permission "keys,",
where each key combines the name of the allowable action as the object for
which the principal needs the required permission.
o For
example the 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.
o
<Array> String permissions: The names 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.
The list below defines all mapping keys, as well as a
permissions mapping that repositories SHOULD use. Repositories MAY require
additional permissions.
For convenience, the list below groups all mapping entries
by the underlying Allowable Actions, and includes descriptive information. For
each Allowable Action the following information is given:
Description: The
description and name of the service the AllowableAction enables.
Base Object: The
base object-types for which the allowable action MAY be TRUE.
Operand: The
object the permission applies to.
Key: The
permission mapping key.
Permissions: The
permission values.
Navigation Services:
canGetDescendants
Description: Can
get the descendants of the folder (getDescendants)
Base Object: cmis:folder
Operand: cmis:folder
Key: canGetDescendants.Folder
Permission: Read
canGetFolderTree
Description: Can get
the sub-folder tree of the folder (getFolderTree)
Base Object: cmis:folder
Operand: cmis:folder
Key: canGetFolderTree.Folder
Permission: Read
canGetChildren
Description: Can
get the children of the folder (getChildren)
Base Object: cmis:folder
Operand: cmis:folder
Key: canGetChildren.Folder
Permission: Read
canGetFolderParent
Description: Can
get the parent/ancestor folder(s) of the folder (getFolderParent)
Base Object: cmis:folder
Operand: cmis:folder
Key: canGetFolderParent.FolderObject
Permission: Read
canGetObjectParents
Description: Can
get the parent folders of the object. (getObjectParents)
Base Object: cmis:document,
cmis:folder, cmis:policy
Operand Object
Key: canGetObjectParents.Object
Permission: Read
Object Services:
canCreateDocument
Description: Can
create a cmis:document Object in the folder (createDocument)
Base Object: cmis:folder
Operand: Folder
Key: canCreateDocument.Folder
Permission: Read
canCreateFolder
Description: Can
create a cmis:folder Object as a child of the specified folder (createFolder)
Base Object: cmis:folder
Operand: Folder
Key: canCreateFolder.Folder
Permission: Read
canCreateRelationship
Description: Can
create a Relationship in which this Object is a source (createRelationship)
Base Object: cmis:document,
cmis:folder
Operand: Object
Key: canCreateRelationship.Source
Permission: Read
canCreateRelationship
Description: Can
create a Relationship in which this Object is a target (createRelationship)
Base Object: cmis:document,
cmis:folder
Operand: Object
Key: canCreateRelationship.Target
Permission: Read
canGetProperties
Description: Can
read the properties of this object (getProperties)
Base Object: cmis:document,
cmis:folder, cmis:relationship, cmis:policy
Operand: Object
Key: canGetProperties.Object
Permission: Read
canGetRenditions
Description: Can
retrieve the renditions of this object (getRenditions)
Base Object: cmis:document,
or cmis:folder
Operand: Object
Key: canGetRenditions.Object
Permission: Read
canGetContentStream
Description: Can
get the content stream for the Document object (getContentStream)
Base Object: cmis:document
Operand: Object
Key: canGetContentStream.Object
Permission: Read
canUpdateProperties
Description: Can
update the properties of this object (updateProperties)
Base Object: cmis:document,
cmis:folder, cmis:relationship, cmis:policy
Operand: Object
Key: canUpdateProperties.Object
Permission: Write
canMoveObject
Description: Can
move the object (moveObject)
Base Object: cmis:document, cmis:folder, cmis:policy
Operand: Object
Key: canMoveObject.Object
Permission: Write
canMoveObject
Description: Can
move an object into this folder (moveObject)
Base Object: cmis:folder
Operand: Folder
Key: canMoveObject.Target
Permission: Read
canMoveObject
Description: Can
move an object from this folder (moveObject)
Base Object: cmis:folder
Operand: Folder
Key: canMoveObject.Source
Permission: Read
canDeleteObject
Description: Can
delete this object (deleteObject)
Base Object: cmis:document,
cmis:folder, cmis:relationship, cmis:policy
Operand: Object
Key: canDelete.Object
Permission: Write
canGetContentStreamcanDeleteObject
Description: Can
delete an object that is a child of this folder (deleteObject)
Base Object: cmis:folderdocument
Action: Can get
the content stream for the Document object (getContentStream)
Operand: FolderObject
Key: canDelete.FoldercanViewContent.Object
Permission: Read
canSetContentStream
Description: Can
set the content stream for the Document object (setContentStream)
Base Object: cmis:document
Operand: Object
Key: canSetContentStream.Document
Permission: Write
canDeleteContentStream
Base Object: cmis:document
Action: Can
delete the content stream for the Document object (deleteContentStream)
Operand: Object
Key: canDeleteContentStream.Document
Permission: Write
canDeleteTree
Base Object: cmis:folder
Action: Can
delete the folder and all contained objects (deleteTree)
Operand: Object
Key: canDeleteTree.Folder
Permission: Write
Filing Services:
canAddObjectToFolder
Description: Can
file the document in a folder (addObjectToFolder)
Base Object: cmis:document, cmis:policy
Operand: Object
Key: canAddToFolder.Object
Permission: Read
canAddObjectToFolder
Description: Can
file a document in the specified folder (addObjectToFolder)
Base Object: cmis:document, cmis:policy
Operand: Object
Key: canAddToFolder.Folder
Permission: Read
canRemoveObjectFromFolder
Description: Can
unfile the specified document from a folder (removeObjectFromFolder)
Base Object: cmis:document, cmis:policy
Operand: Object
Key: canRemoveObjectFromFolder.Object
Permission: Read
canRemoveObjectFromFolder
Description: Can
unfile a document from the specified folder (removeObjectFromFolder)
Base Object: cmis:document, cmis:policy
Operand: Object
Key: canRemoveObjectFromFolder.Folder
Permission: Read
Versioning Services:
canCheckOut
Description: Can
check out the Document object (checkOut)
Base Object: cmis:document
Operand: Object
Key: canCheckOout.Document
Permission: Write
canCancelCheckOut
Description: Can
cancel the check out the Document object (cancelCheckOut)
Base Object: cmis:document
Operand: Object
Key: canCancelCheckout.Document
Permission: Write
canCheckIn
Description: Can
check in the Document object (checkIn)
Base Object: cmis:document
Operand: Object
Key: canCheckin.Document
Permission: Write
canGetAllVersions
Description: Can
get the version series for the Document object (getAllVersions)
Base Object: cmis:document
Operand: Object
Key: canGetAllVersions.DocumentVersionSeries
Permission: Read
Relationship Services:
canGetObjectRelationships
Description: Can
get the relationship in which this object is a source/target (getObjectRelationships)
Base Object: cmis:document, cmis:folder, cmis:policy
Operand: Object
Key: canGetObjectRelationships.Object
Permission: Read
Policy Services:
canApplyPolicy
Description: Can
apply a policy to the Object (applyPolicy)
Base Object: cmis:document, cmis:folder
Operand: Object
Key: canAddPolicy.Object
Permission: Read
canApplyPolicy
Description: Can
apply the specified policy to an Object (applyPolicy)
Base Object: cmis:policy
Operand: Object
Key: canAddPolicy.Policy
Permission: Read
canRemovePolicy
Description: Can
remove a policy from the specified Object (removePolicy)
Base Object: cmis:document, cmis:folder
Operand: Object
Key: canRemovePolicy.Object
Permission: Read
canRemovePolicy
Description: Can
remove the specified policy from an Object (removePolicy)
Base Object: cmis:document, cmis:folder
Operand: cmis:policy
Key: canRemovePolicy.Policy
Permission: Read
canGetAppliedPolicies
Description: Can
get the list of Policies applied to the Object (getAppliedPolicies)
Base Object: cmis:document, cmis:folder
Operand: Object
Key: canGetAppliedPolicies.Object
Permission: Read
ACL Services:
canGetACL
Description: Can
get ACL for object (getACL)
Base Object: cmis:document,
cmis:folder, cmis:relationship, cmis:policy
Operand: Object
Key: canGetACL.Object
Permission: Read
canApplyACL
Description: Can
apply ACL to this object (applyACL)
Base Object: cmis:document,
cmis:folder, cmis:relationship, cmis:policy
Operand: Object
Key: canApplyACL.Object
Permission: Write
CMIS supports versioning of Document objects. Folder
objects, relationship objects, and policy 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 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 ObjectId,
property values, MAY be acted upon using all CMIS services that act upon
Document objects, etc.
A version
series for a Document object is a transitively closed collection of all
Document objects that have been created from an original Document in the
Repository. Each version series has a unique, system-assigned, and immutable 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 CreationDate properties.
Additionally, the repository MAY expose a textual 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.
The version that has the most recent LastModificationDate
is called the 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.
2.1.9.2.1 Behavioral constraints on non-Latest Versions
Repositories NEED NOT allow the non-latest versions in a
Version Series to be updated, queried, or searched.
A Document object in a Version Series MAY be designated as a
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 LastModificationDate is the 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.
2.1.9.4.1 Checkout
A new version of a versionable Document object is created when
the checkIncheckIn
service is invoked on the Private Working copy (PWC) of this object. A PWC
is created by invoking 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 checkout service MUST be
as follows:
- A
new Document object, referred to herein as the Private Working Copy (PWC),
is created.
o The PWC
NEED NOT be visible to users who have permissions to view other Document
objects in the Version Series.
o Until it
is checked in (using the checkIn service), the PWC MUST NOT be
considered the LatestMajorVersion in the Version Series.
o The
property values for the PWC SHOULD be identical to the properties of the
Document object on which the checkout service was invoked. Certain
properties such as cmis:objectId may be different. Properties such as
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 checkout
service was invoked, or MAY be "not
set.".
After a successful checkout operation is completed,
and until such time when the PWC is deleted (via the cancelCheckOut service)
or checked-in (via the checkIn) service, the effects on other Documents
in the Version Series MUST be as follows:
- The
repository MUST throw an exception if the 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.)
- The
value of the cmis:isVersionSeriesCheckedOut property MUST be TRUE.
- The
value of the cmis:versionSeriesCheckedOutBy property MAY be set to a value
indicating which user created the PWC. (The Repository MAY still show the
"not
set"
value for this property.)
- The
value of the cmis:versionSeriesCheckedOutId property MAY be set to the
ObjectId of the PWC. (The Repository MAY still show the
"not
set"
value for this property).
- The
repository MAY prevent operations that modify or delete the other
Documents in the Version Series.
2.1.9.4.2 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. UpdateProperties).
If the repository does NOT support the "PWCUpdatable"
capability, then the PWC object can only be modified as part of the checkIn service
call.
2.1.9.4.3 Discarding Check out
An authorized user MAY discard the check-out using the cancelCheckOut
service on any Document in the Version Series or by using the deleteObject
service on the PWC Object. The effects of discarding a check-out MUST be as
follows:
- The
PWC Object MUST be deleted.
- For
all other Documents in the Version Series:
o The value
of the cmis:isVersionSeriesCheckedOut property MUST be FALSE.
o The value
of the cmis:versionSeriesCheckedOutBy property MUST be "not
set.".
o The value
of the cmis:versionSeriesCheckedOutId property MUST be "not
set.".
o The repository
MUST allow authorized users to invoke the checkout service.
2.1.9.4.4 Checkin
An authorized user/application MAY "check
in"
the Private Working Copy object via the checkIn service.
The checkIn service allows users/applications to
provide update property values and a content-stream for the PWC object.
The effects of the checkIn service MUST be as follows for
successful checkins:
·
The PWC object MUST be updated as specified by the inputs to the checkIn
service. (Note that for repositories that do NOT support the "PWCUpdatable"
property, this is the only way to update the PWC object.)
·
The Document object resulting from the checkIn operation
MUST be considered the Latest Version in the Version Series.
·
If the inputs to the checkIn service specified that the PWC
MUST be a "major
version,",
then the PWC MUST be considered the Latest Major Version in the Version
Series.
·
If the checkin returns a new cmis:objected, then the PWC object
MUST disappear if the checkIn call was successful and the new checked in
version will use the new specified id.
·
For all Documents in the Version Series:
o The value
of the cmis:isVersionSeriesCheckedOut property MUST be FALSE.
o The value
of the cmis:versionSeriesCheckedOutBy property MUST be "not
set.".
o The value
of the cmis:versionSeriesCheckedOutId property MUST be "not
set.".
o The
repository MUST allow authorized users to invoke the checkout service.
Note: The Repository MAY change the ID of the PWC
upon completion of the checkin service invocation.
Note: A repository MAY automatically create new
versions of Document objects without an explicit invocation of the
checkout/checkin services.
2.1.9.5 Versioning Properties on
Document Objects
All Document objects will have the following read-only
property values pertaining to versioning:
cmis:isLatestVersion Boolean
TRUE if the Document object is the Latest
Version in its Version Series. FALSE otherwise.
cmis:isMajorVersion Boolean
TRUE if the Document object is a Major
Version in its Version Series. FALSE otherwise.
cmis:isLatestMajorVersion Boolean
TRUE if the Document object is the Latest
Major Version in its Version Series. FALSE otherwise.
cmis:versionLabel String (optional)
Optional textual description the
position of an individual object with respect to the version series. (For example,
version 1.0).
cmis:versionSeriesId ID
ID of the Version Series for this
Object.
cmis:isVersionSeriesCheckedOut Boolean
TRUE if there currenly exists a
Private Working Copy for this Version Series. FALSE otherwise
cmis:versionSeriesCheckedOutBy String
If IsVersionSeriesCheckedOut is
TRUE: then an identifier for the user who created the Private Working Copy. "Not
set"
otherwise.
cmis:versionSeriesCheckedOutId ID
If IsVersionSeriesCheckedOut is
TRUE: The Identifier for the Private Working Copy. "Not
set"
otherwise.
cmis:checkinComment String
Textual comment associated with
the given version.
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 cmis:lastModificationDate, etc.)
A repository MAY create new Document objects in a "Private
Working Copy"
state when they are created via the createDocument or
createDocumentFromSource services. 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 versioningState parameter.
2.1.9.7
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 "VersionSpecificFiling"
optional capability flag.
If the repository is treating folder collection membership
as "version-independent,",
then:
·
Moving or Filing a Document Object into a folder MUST result in
ALL Documents in the Version Series being moved/filed into the folder.
·
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 (getChildren, getDescendants), and NEED NOT return other
Document Objects filed in the folder that are in the Version Series.
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.
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:
·
The 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.
If a relationship object has a version-specific binding to
its source/target object, then:
·
The 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.
2.1.9.9 Versioning
visibility in Query Services
Repositories MAY include non-latest-versions of Document
Objects in results to the Discovery Services (query).
Repositories MUST indicate whether they support querying for
non-latest-versions via the "AllVersionsSearchable"
optional capability flag.
If "AllVersionsSearchable"
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 in results to
the Discovery Services (query).
Repositories MUST indicate whether they support querying for
Private Working Copy objects via the "PWCSearchable"
optional capability flag.
If "PWCSearchable"
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 "PWCSearchable"
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.)
2.1.10 Query
CMIS provides a type-based query service for discovering
objects that match specified criteria, by defining a read-only projection of
the CMIS data model into a Relational View.
Through this relational view, queries may be performed via a
simplified SQL SELECT statement. This query language is based on a subset of
the SQL-92 grammar (ISO/IEC 9075: 1992 Database Language SQL), with a few
extensions to enhance its filtering capability for the CMIS data model, such as
existential quantification for multi-valued property, full-text search, and
folder membership. Other statements of the SQL language are not adopted by
CMIS. The semantics of this query language is defined by the SQL-92 standard,
plus the extensions, in conjunction with the model mapping defined by CMIS's
relational view.
The relational view of a CMIS repository consists of a
collection of virtual tables that are defined on top of the CMIS data model. This
relational view is used for query purposes only.
In this relational view a Virtual
Table is implicitly defined for each queryablequeryable
Object-Type defined in the repository. (Non-queryable Object-Types are NOT
exposed through this Relational View.)
In each Virtual Table, a Virtual
Column is implicitly defined for each property defined in the Object-Type
Definition AND for all properties defined on ANY ancestor-type of the
Object-Type but NOT defined in the Object-Type definition. Virtual Columns for
properties defined on ancestor-types of the Object-type but NOT defined in the
Object-Type definition MUST contain the SQL NULL value. Virtual Columns for
properties whose value is "not
set"
MUST contain the SQL NULL value.
An object-type's
queryName attribute is used as the table name for the corresponding
virtual table, and a property's queryName
attribute is used as the column name for the corresponding table column.
Please see the restrictions on queryName in the appropriate data model section.
The Virtual Column for a
multi-valued property MUST contain a single list value that includes all values
of the property.
2.1.10.1.1 Object-Type Hierarchy in the Relational View Projection
The Relational View projection of
the CMIS Data Model ensures that the Virtual Table for a particular Object-type
is a complete super-set of the Virtual Table for any and all of its ancestor
types.
Additionally, an Object-Type
definition's "includedInSupertypeQuery"
specifies whether objects of that Object-Type MUST be included in the
Virtual Table for any of its ancestor types. If the "includedInSupertypeQuery"
attribute of the Object-Type is FALSE, then objects of that Object-Type
MUST NOT be included in the Virtual Table for any of its ancestor types.
Thus the Virtual Table for an
Object-type includes a row not only for each Object of that type, but all
Objects of any of that Object-types'
Descendant Types for which the "includedInSupertypeQuery"
attribute is TRUE.
But since the Virtual Table will
include only columns for properties defined in the Object-Type underlying the
Virtual Table, a row that is a query result representing an Object of a
Descendant Type can only include those columns for properties defined on the
Object-Type underlying the Virtual Table.
2.1.10.1.2 Content Streams
Content-streams are NOT exposed
through this relational view.
2.1.10.1.3
Result Set
When a query is submitted, a set of pseudo CMIS objects will
be returned. These pseudo objects are comprised of the properties specified in
the select clause of the query statement.
For each property in each object in the result set, the
Repository MUST include the property definition ID as well as either the query
name (if no alias is used) or the alias in place of the query name (if an alias
is used).
If the select clause of the query statement contains
properties from a single type reference then the repository MAY represent these
pseudo-objects with additional object information.
This query languages is based on a subset of the SQL-92
grammar. CMIS-specific language extensions to SQL-92 are called out explicitly.
The basic structure of a CMIS query is a SQL statement that
MUST include the following clauses:
- SELECT
[virtual columns]: This clause identifies the set of virtual columns
that will be included in the query results for each row.
- FROM
[Virtual Table Names]: This clause identifies which Virtual Table(s)
the query will run against.
Additionally, a CMIS query MAY include the following
clauses:
- WHERE
[conditions]: This clause identifies the constraints that rows MUST
satisfy to be considered a result for the query.
- ORDER
BY [sort specification]: This clause identifies the order in which the
result rows MUST be sorted in the result row set.
2.1.10.2.1 BNF Grammar
This BNF grammar is a "subset"
of the SQL-92 grammar (ISO/IEC 9075: 1992 Database Language SQL), except for
some production alternatives. Specifically, except for these extensions, the
following production rules are derived from the SQL-92 grammar. The
non-terminals used in this grammar are also borrowed from the SQL-92 grammar
without altering their semantics. Accordingly, the non-terminal <column
name> is used for single-valued properties only so that the semantics of SQL
can be preserved and borrowed. This approach not only facilitates comparison of
the two query languages, and simplifies the translation of a CMIS query to a
SQL query for a RDBMS-based implementation, but also allows future expansion of
this query language to cover a larger subset of SQL with minimum conflict. The
CMIS extensions are introduced primarily to support multi-valued properties and
full-text search, and to test folder membership. Multi-valued properties are
handled separately from single-valued properties, using separate non-terminals
and separate production rules to prevent the extensions from corrupting SQL-92
semantics.
<CMIS 1.0 query statement> ::= <simple table> [
<order by clause> ]
<simple table> ::= SELECT <select list> <from
clause> [ <where clause> ]
<select list> ::= *"*"
| <select sublist> [ { ,","
<select sublist> }
]
<select sublist> ::= <value expression> [ [ AS ]
<column name> ]
| <qualifier> .*".*"
| <multi-valued-column
reference>
<value expression> ::= <column reference> |
<numeric value function>
<column reference> ::= [ <qualifier> ."."
] <column name>
<multi-valued-column reference> ::= [
<qualifier> ."."
] <multi-valued-column name>
<numeric value function> ::= SCORE()
<qualifier> ::= <table name> | <correlation name>
<from clause> ::= FROM <table reference>
<table reference> ::= <table name> [ [ AS ]
<correlation name> ]
| <joined table>
<joined table> ::= ("("
<joined table> )")"
| <table reference> [ <join type> ]
JOIN <table reference> <join specification>
<join type> ::= INNER | LEFT [ OUTER ]
<join specification> ::= ON <column reference> "="
<column reference>
<where clause> ::= WHERE <search condition>
<search condition> ::= <boolean term> |
<search condition> OR <boolean term>
<boolean term> ::= <boolean factor> |
<boolean term> AND <boolean factor>
<boolean factor> ::= [ NOT ] <boolean test>
<boolean test> ::= <predicate> | ("("
<search condition> )")"
<predicate> ::= <comparison predicate> | <in
predicate> | <like predicate> | <null predicate>
| <quantified comparison
predicate> | <quantified in predicate>
| <text search predicate> |
<folder predicate>
<comparison predicate> ::= <value expression>
<comp op> <literal>
<comp op> ::= = | <> |
< | > | <= | >="=" | "<>"
| "<" | ">" | "<=" | ">="
<literal> ::= <signed numeric literal> |
<character string literal> | <datetime literal> | <boolean
literal>
<in predicate> ::= <column reference> [ NOT ] IN
("("
<in value list> )")"
<in value list> ::= <literal> [{ ,","
<literal> }
]
<like predicate> ::= <column reference> [ NOT ]
LIKE <character string literal>
<null predicate> ::= { <column reference> |
<multi-valued-column reference> } IS [ NOT ] NULL
<quantified comparison predicate> ::= <literal> ="="
ANY <multi-valued-column reference>
<quantified in predicate> ::= ANY
<multi-valued-column reference> [ NOT ] IN ("("
<in value list> )")"
<text search predicate> ::= CONTAINS "("
[ <qualifier> ","
] <quote> <text search expression> <quote> ")"
<folder predicate> ::= { IN_FOLDER | IN_TREE } ("("
[ <qualifier> ,","
] <folder id> )")"
<order by clause> ::= ORDER BY <sort
specification> [ { ,","
<sort specification> }
]
<sort specification> ::= <column reference> [
ASC | DESC ]
<correlation name> ::= <identifier>
<table name> ::= <identifier> !! This MUST
be the name of an object-type.
<column name> ::= <identifier> !! This MUST be
the name of a single-valued property,
or an
alias for a scalar output value.
<multi-valued-column name> ::= <identifier> !!
This MUST be the name of a multi-valued property.
<folder id> ::= <character string literal> !!
This MUST be the object identity of a folder object.
<identifier> ::= !! As
defined by queryName attribute.
<signed numeric literal> ::= !! As defined by
SQL-92 grammar.
<character string literal> ::= !! As defined by
SQL-92 grammar. (i.e. enclosed in single-quotes)
!! This is an independent sub-grammar for full-text
search criteria. It is isolatable from the query statement
grammar. (See 2.1.10.3 Escaping)
<text search expression> ::= <conjunct> [ {<space>
OR <space> <conjunct>}
]
<conjunct> ::= <term> [ {<space>
<term>}
]
<term> ::= ['-'] <simple term>
<simple term> ::= <word> | <phrase>
<word> ::= <non space char> [ {<non space
char>}
]
<phrase> ::= <quote> <word> [ {<space>
<word>}
] <quote>
<space> ::= <space char> [ {<space char>}
]
<non space char> ::= <char> - <space char>
<space char> ::= ' '
<char> ::= !! Any character
<datetime literal> ::= TIMESTAMP <quote>
<datetime string> <quote>
<datetime string> ::= YYYY-MM-DDThh:mm:ss.sss[Z |
+hh:mm | -hh:mm]
<boolean literal> ::= TRUE | FALSE | true | false
<quote> ::= "'" !!
Single-quote only, consistent with SQL-92 string literal
2.1.10.2.2 SELECT Clause
The SELECT clause MUST contain exactly one of the following:
- A
comma separated list of one or more column names.
o If an
explicit column list is provided: A repository MUST include in its result row
set all of the columns specified in the SELECT clause.
- *
: If this token is specified, then the repository MUST return columns for
ALL single-valued properties defined in the Object-Types whose Virtual
Tables are listed in the FROM clause, and SHOULD also return all
multi-valued properties.
All column names MUST be valid "queryName"
values for properties that are defined as "queryable"
in the Object-Type(s) whose Virtual Tables are listed in the FROM clause.
2.1.10.2.3 FROM Clause
The FROM clause identifies which Virtual Table(s) the query
will be run against, as described in the previous section.
The FROM clause MUST contain only the queryNames of
Object-Types whose queryable attribute value is TRUE.
2.1.10.2.3.1 Join Support
CMIS repositories MAY support the use of SQL JOIN queries,
and MUST indicate their support level using the Optional
Capability attribute capabilityJoin.Optional Capability
attribute "capabilityJoin".
- If
the Repository
's
value for the capabilityJoin attribute is none, then no JOIN
clauses can be used in queries.
- If
the Repository
's
value for the capabilityJoin attribute is inneronly, then only
inner JOIN clauses can be used in queries.
- If
the Repository
's
value for the capabilityJoin attribute is innerandouter, then inner
and/or outer JOIN clauses can be used in queries.
Only explicit joins using the "JOIN"
keyword is supported. Queries MUST NOT include implicit joins as part of the
WHERE clause of a CMIS query.
CMIS queries MUST only support join operations using the "equality"
predicate on single-valued properties.
2.1.10.2.4 WHERE Clause
This clause identifies the constraints that rows MUST
satisfy to be considered a result for the query.
All column names MUST be valid "queryName"
or their aliased values for properties that are defined as "queryable"
in the Object-Type(s) whose Virtual Tables are listed in the FROM clause.
Properties are defined to not support a "null"
value, therefore the <null predicate> MUST be interpreted as testing the
not set or set state of the specified property.
2.1.10.2.4.1 Comparisons
permitted in the WHERE clause.
SQL's
simple comparison predicate, IN predicate, and LIKE predicate are supported,
for single-valued properties only (so that SQL's
semantics is preserved). Boolean conjunction (AND), disjunction (OR), and
negation (NOT) of predicates are also supported.
Repositories SHOULD support the comparisons for the property
types as described in the list below. Repositories MAY support additional
comparisons and operators. Any additional operators not specified are
repository-specific:
<Property Type>
Supported Operators: <List of Operators supported on
Type>
Supported Literal: <Supported type of Literal in
comparison>
String (Single)
Supported Operators: =, <>, [NOT] LIKE
Supported Literal: String
String (IN)
Supported Operators: [NOT] IN
Supported Literal: List of Strings
Decimal
Supported Operators: =, <>, <, <=, >, >=
Supported Literal: Decimal
Decimal (IN)
Supported Operators: [NOT] IN
Supported Literal: List of Decimal
Integer
Supported Operators: =, <>, <, <=, >, >=
Supported Literal: Integer
Integer (IN)
Supported Operators: [NOT] IN
Supported Literal: List of Integer
Boolean
Supported Operators: =
Supported Literal: <boolean literal>
DateTime
Supported Operators: =, <>, <*, <=*, >*,
>=*
Supported Literal: <datetime literal>
* - comparison is based on chronological before or after
date.
DateTime (IN)
Supported Operators: [NOT] IN
Supported Literal: List of <datetime literal>s's
ID
Supported Operators: =, <>
Supported Literal: String
ID (IN)
Supported Operators: [NOT] IN
Supported Literal: List of strings
URI
Supported Operators: =, <>
Supported Literal: String
URI (IN)
Supported Operators: [NOT] IN
Supported Literal: List of strings
URI
Supported Operators: [NOT] LIKE
Supported Literal: String
Operations on the SCORE() output MUST be treated the same as
decimal operations.
When using properties in a join statement, comparison MUST
be allowed on properties of the same types as defined by the table above.
Repositories MAY extend this behavior.
The ANY operation argument MUST be one of the properties
found in the table above which supports equality operations
2.1.10.2.4.2 Multi-valued
property support (SQL-92 Extension)
The CMIS query language includes several new non-terminals
to expose semantics for querying multi-valued properties, in a way that does
not alter the semantics of existing SQL-92 production rules.
2.1.10.2.4.2.1
Multi-valued column references
BNF grammar structure: <Multi-valued-column
reference>, <multi-valued-column name>
·
These are non-terminals defined for multi-valued properties
whereas SQL-92's
<column reference> and <column name> are retained for single-valued
properties only. This is to preserve the single-value semantics of a regular "column"
in the SQL-92 grammar.
2.1.10.2.4.2.2
<Quantified comparison predicate>
The SQL-92
production rule for <quantified comparison predicate> is extended to
accept a multi-valued property in place of a <table subquery>. This
operation is restricted to equality tests only.
<Table
subquery> is not supported in CMIS-SQL.
The SQL-92 <quantifier> is restricted to ANY only.
The SQL-92 <row
value constructor> is restricted to a literal only.
Example:
SELECT Y.CLAIM_NUM, X.PROPERTY_ADDRESS, Y.DAMAGE_ESTIMATES
FROM ( POLICY AS X JOIN CLAIMS AS Y ON (
X.POLICY_NUM = Y.POLICY_NUM )
WHERE ( 100000 = ANY Y.DAMAGE_ESTIMATES )
(Note: DAMAGE_ESTIMATES is a
multi-valued Integer property.)
2.1.10.2.4.2.3
IN/ANY Predicate
BNF grammar structure: <Quantified in
predicate>
CMIS-SQL exposes a
new IN predicate defined for a multi-valued property. It is modeled after the
SQL-92 IN predicate, but since the entire predicate is different semantically,
it has its own production rule in the BNF grammar below.
The quantifier is
restricted to ANY. The predicate MUST be evaluated to TRUE if at least one of
the property's values
is (or, is not, if NOT is specified) among the given list of literal values.
Otherwise the predicate is evaluated to FALSE.
The ANY operation argument MUST be one of the properties
found in the comparison list above which supports IN operations.
Example:
SELECT *
FROM CAR_REVIEW
WHERE (MAKE = 'buick'
) OR
( ANY FEATURES IN (NAVIGATION SYSTEM,
SATELLITE RADIO, MP3('NAVIGATION SYSTEM', 'SATELLITE
RADIO', 'MP3') ) (Note: FEATURES is a multi-valued String property.)
2.1.10.2.4.3 CONTAINS()
predicate function (CMIS-SQL Extension)
BNF grammar structure:: CONTAINS
( [ <qualifier> ,] '
<text search expression> '
)
Usage: This is a predicate
function that encapsulates the full-text search capability that MAY be provided
by a Repository (See previous section.)(See
previous section.)
Inputs:
<Qualifier>
The value of this optional parameter
MUST be the name of one of the Virtual Tables listed in the FROM clause for the
query.
o If
specified, then the predicate SHOULD only be applied to objects in the
specified Virtual Table, but a repository MAY ignore the value of the
parameter.
o If
not specified, applies to the single virtual table. If the query is a join, a
server SHOULD throw an exception if the qualifier is not specified.
<Text Search
Expression>
The <text search expression>
parameter MUST be a character string , specifying the full-text search
criteria.
The Text Search Expression may be a set
of terms or phrases with an optional -'-'
to signal negation. A phrase is defined as a word or group of words. A group
of words must be surrounded by quotes to be considered a single phrase.
Terms separated by whitespace are
AND'ed
together.
Terms separated by "OR"
are OR'ed
together
Implicit "AND"
has higher precedence than "OR"
Within a word or phrase, each
(single-)quote must also be escaped by a preceding backslash \"\"
Return value:
The predicate returns a Boolean
value.
The predicate MUST return TRUE if
the object is considered by the repository as "relevant"
with respect to the given <text search expression> parameter.
The predicate MUST return FALSE if
the object is considered by the repository as not "relevant"
with respect to the given <text search expression> parameter.
Constraints:
At most one CONTAINS() function
MUST be included in a single query statement. The repository MUST throw an
exception if more than one CONTAINS() function is found.
The return value of
the CONTAINS() function MAY only be included conjunctively (ANDed) with the
aggregate of all other predicates, if there is any, in the WHERE clause.
2.1.10.2.4.4 SCORE()
predicate function
BNF grammar structure: SCORE ()
Usage: This is a predicate function
that encapsulates the full-text search capability that MAY be provided by a
Repository (See previous section.)(See
previous section.)
Inputs: No inputs MUST be
provided for this predicate function.
Return value:
The SCORE() predicate function
returns a decimal value in the interval [0,1] .
A repository MUST return the value
0 if the object is considered by the repository as having absolutely no
relevance with respect to the CONTAINS() function specified in the query.
A repository MUST return the value
1 if the object is considered by the repository as having absolutely complete
relevance with respect to the CONTAINS() function specified in the query.
Constraints:
The SCORE() function MUST only be
used in queries that also include a CONTAINS() predicate function
The SCORE() function MUST only be
used in the SELECT clause of a query. It MUST NOT be used in the WHERE clause
or in the ORDER BY clauses.
An alias column name defined for
the SCORE() function call in the SELECT clause (i.e., "SELECT SCORE() AS
column_name
") may be used in the ORDER BY clause.
If SCORE() is included in the
SELECT clause and an alias column name is not provided, then a query name of
SEARCH_SCORE is used for the query output, and the property definition ID is
repository-specific.
2.1.10.2.4.5 IN_FOLDER()
predicate function
BNF grammar structure: IN_FOLDER( [ <qualifier>, ] <folder id> )
Usage: This is a predicate
function that tests whether or not a candidate object is a child-object of the
folder object identified by the given <folder id>.
Inputs:
<qualifier>
The value of this optional parameter
MUST be the name of one of the Virtual Tables listed in the FROM clause for the
query.
· If
specified, then the predicate SHOULD only be applied to objects in the
specified Virtual Table, but a repository MAY ignore the value of the
parameter.
· If
not specified, applies to the single virtual table. If the query is a join, a
server SHOULD throw an exception if the qualifier is not specified.
<folder
id>
The value of this
parameter MUST be the ID of a folder object in the repository.
Return value:
The predicate function MUST return TRUE
if the object is a child-object of the folder specified by <folder id>.
The predicate function MUST return
FALSE if the object is a NOT a child-object of the folder specified by
<folder id>.
2.1.10.2.4.6 IN_TREE()
predicate function
BNF grammar structure: IN_TREE( [ <qualifier>, ] <folder id> )
Usage: This is a predicate
function that tests whether or not a candidate object is a descendant-object of
the folder object identified by the given <folder id>.
Inputs:
<qualifier>
The value of this optional parameter
MUST be the name of one of the Virtual Tables listed in the FROM clause for the
query.
o If
specified, then the predicate SHOULD only be applied to objects in the
specified Virtual Table, but a repository MAY ignore the value of the
parameter.
o If
not specified, applies to the single virtual table. If the query is a join, a
server SHOULD throw an exception if the qualifier is not specified.
<folder id>
The value of this
parameter MUST be the ID of a folder object in the repository.
Return value:
The predicate function MUST return TRUE
if the object is a descendant-object of the folder specified by <folder
id>.
The predicate function MUST return
FALSE if the object is a NOT a descendant -object of the folder specified by
<folder id>.
2.1.10.2.5 ORDER BY Clause
This clause MUST contain a comma separated list of one or
more column names.
All column names referenced in this clause MUST be valid "queryName"
or th
