Proposal: Document Management Services

Copyright © 2010 MISMO Inc. – Draft 0.2 dated 8/16/2010

The goal of the Document Management Services project is to provide a standard within the MISMO reference model for messages that support the movement of collections of documents between Electronic Content Management (ECM) repositories. Where it is practical, we intend to reference and make use of the OASIS Content Management Interoperability Services (CMIS) standard. Following is our proposal to add new data elements and containers to the MISMO reference model in support of our goal.

The MISMO V3 model defines the structure and content of any MISMO message. Where it is practical, a MISMO message is a single content item. However, a MISMO message such as a loan pool may become very large, making it impractical to provide all message content in a single item. When this happens, the model provides a way to divide the large message into a smaller primary message and many included content items such as MISMO documents or deals. The now-smaller primary message includes the many content items by referring to them using the model's REFERENCE element with a LocationURL and LocationXPath. This Document Management Services proposal shows how to persist the referenced content items in a CMIS repository.

According to the MISMO V3 model schema, “a message recipient MAY replace the content of the referenced location for the REFERENCE element before processing or may process the information from that location.” Persisting the referenced content item in a CMIS repository permits the second alternative, processing the information directly within the CMIS repository, and in an interoperable way. An application that implements this Document Management Services guidance will understand how to access and manage the content items in a CMIS repository. For many use cases this is simpler than the first alternative of having to replace the reference in the original message before processing the content items.

Until this proposal is approved by MISMO, we will keep it updated with the most current MISMO model release. This proposal version is current with Reference_Model_v3_1_DRAFT_B278_20100806.

Document Version History

Version	Description
0.1	Initial version.
0.2	Added copyright. Expanded preface. Expanded description of cmis:folder Added section regarding REFERENCE. Added Appendix 2. Changed “LocationURI” to “LocationURL” in Appendix 2.

Table of Contents

CMIS: Content Management Interoperability Services

 

A Short Introduction to CMIS

The MISMO V3 reference model defines the structure and content of any MISMO message. A MISMO message has two major branches. The DEAL_SETS branch is where the data involved in a mortgage industry transaction is found, and the DOCUMENT_SETS branch is where the documents involved in a mortgage industry transaction occur. Most MISMO work groups are engaged in creating useful services based on DEAL_SETS data – services like ordering flood certificates, canceling mortgage insurance, and requesting credit reports. The goal of the Document Management Services work group is to define useful services based on DOCUMENT_SETS documents, where no such services are yet defined. This proposal shows how the DMS work group suggests the MISMO V3 model be enhanced to support document services.

To promote Document Management Services interoperability among mortgage industry participants, this DMS proposal is predicated upon using the recent OASIS Content Management Interoperability Services 1.0 standard. CMIS is often called “the SQL for content systems” because it is the first widely adopted data model and query language for unstructured content. The CMIS standard defines a domain model – a common document management vocabulary – so that trading partners use consistent terms, like “cmis:name” for the name of a document. Then it defines a set of common tasks that can be performed upon documents that use the CMIS domain model, tasks like “create the document”, “get the document”, and “delete the document”. Finally, it defines how to express those tasks as both SOAP and REST style Web Services, between which trading partners may choose.

Using the CMIS standard as the foundation for MISMO Document Management Services has two benefits. First, using CMIS means any DMS client implementation should work with any DMS server implementation, and vice versa, which reduces the need to implement proprietary DMS interfaces and lowers MISMO DMS implementation costs. Second, using CMIS means there will be many commercial and open source off-the-shelf CMIS software products to choose from, forming a competitive market that also results in reduced MISMO DMS implementation costs. In other words, using CMIS as the vocabulary for MISMO Document Management Services means the costs of both “make” and “buy” decisions is lower. In addition, using CMIS reduces the costs of switching repositories.

References:

• CMIS Home: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cmis

• CMIS 1.0 Standard: http://docs.oasis-open.org/cmis/CMIS/v1.0/os/cmis-spec-v1.0.html

• CMIS Cover Pages: http://xml.coverpages.org/cmis.html

A Proposal to Add CMIS as an Approved Acronym

The DMS work group will propose that “CMIS” become a MISMO approved acronym and be added to the acronym list in MEG0008. Within this proposal we have assumed that “CMIS” is already an approved acronym, and so we are using “CMIS” within the data element names. If “CMIS” is not an approved acronym, then we will have to use its expansion in these element names, resulting in in very long and difficult-to-read element names like “ContentManagementInteroperabilityServicesLastModificationDate”. We feel that the CMIS acronym meets both criteria provided in MEG0008: 1) “CMIS” is commonly understood and widely used, and is more familiar than its underlying meaning “Content Management Interoperability Services”; and 2) “CMIS” will be used frequently within the Logical Data Dictionary.

References:

MEG0008 Acronyms and Abbreviations: http://wiki.mismo.org/MISMO.Wiki/Wiki.jsp?page=Meg0008

A description of CMIS document and folder objects

The CMIS 1.0 standard defines four types of objects – things that you may work with in a document management system. This DMS proposal concerns itself with two of the four CMIS objects, documents and folders.

You may think of most any electronic mortgage document as a CMIS document. Take for example a Note that you have scanned and stored as a TIFF file. That file representation of the Note has several well-known attributes, such as the date it was created (2010-08-02), its name (Note), the name of the person who scanned it (Joseph Blow), and the type of electronic data therein (TIF). What the CMIS standard brings is specific names for these document attributes, so that everyone who conforms to the standard uses the same name for the same document attribute. For example, CMIS requires me to call the user who created the document the “cmis:createdBy”, instead of the “DocumentCreator” or something else similar. There is no confusion when everyone uses the same name for the person who created the document: cmis:createdBy is “Joseph Blow”. CMIS documents all have the following properties. Again, what's important here is that everyone uses the same property names, not what those names mean (although that becomes important later on):

CMIS Document Properties

cmis:name	Name of the object
cmis:objected	Id of the object
cmis:baseTypeId	Id of the base object-type for the object
cmis:objectTypeId	Id of the object’s type
cmis:createdBy	User who created the object.
cmis:creationDate	DateTime when the object was created.
cmis:lastModifiedBy	User who last modified the object.
cmis:lastModificationDate	DateTime when the object was last modified.
cmis:changeToken	Opaque token used for optimistic locking & concurrency checking.
cmis:isImmutable	TRUE if the repository MUST throw an error at any attempt to update or delete the object.
cmis:contentStreamLength	Length of the content stream (in bytes).
cmis:contentStreamMimeType	MIME type of the Content Stream
cmis:contentStreamFileName	File name of the Content Stream
cmis:contentStreamId	Id of the stream

Note that the table above omits document property names that are only used in CMIS document versioning tasks, because document versioning is currently out of scope for MISMO Document Management Services.

Similarly, you may think of the place you store your scanned electronic TIF Note document as a CMIS folder. Say for instance you store your Note in a folder you call “Note”. What the CMIS standard brings is specific names for the properties of your “Note” folder. For example, the CMIS calls your folder name “cmis:name”, meaning that the cmis:name of your folder is “Note”

CMIS Folder Properties

cmis:name	Name of the object
cmis:objected	Id of the object
cmis:baseTypeId	Id of the base object-type for the object
cmis:objectTypeId	Id of the object’s type
cmis:createdBy	User who created the object.
cmis:creationDate	DateTime when the object was created.
cmis:lastModifiedBy	User who last modified the object.
cmis:lastModificationDate	DateTime when the object was last modified.
cmis:changeToken	Token used for optimistic locking & concurrency checking.
cmis:parentId	ID of the parent folder of the folder.
cmis:path	The fully qualified path to this folder, which includes this folder name.
cmis:allowedChildObjectTypeIds	Id’s of the set of Object-types that can be created, moved or filed into this folder.

CMIS documents and CMIS folders share many property names. Primary differences are that 1) documents have content streams – which are analogous to a file in a file system – but folders do not, and 2) folders have a cmis:path but documents do not.

A cmis:path is represented by (from CMIS 2.1.5.3):

• ‘/’ 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 segment names must not include a ‘/’ character.

• Within a folder, folder and object path segment names must be unique.

cmis:path conforms to the MISMOXPath type (Does it? MIXMOXPath is just an xsd:string and MEG0007 section 7.6.22 provides no guidance.), making it possible to use an existing MISMO V3 MISMOXPath type element to represent CMIS folder cmis:path property values.

Get document using REFERENCE

The MISMO V3 model includes a REFERENCE container element that is used to permit some MISMO message content to be persisted externally to the message, and included by reference in the message as if it is actually there. The best definition of REFERENCE comes from the unpublished description of MISMO V3 SMART Documents we publish here as Appendix 2, which is:

“The REFERENCE container identifies an alternate location (URI) and identification (XPath) for content that is valid inside the instance’s version of the MISMO model. The content at the alternate location must be a valid MESSAGE, DEAL, or DOCUMENT (JHL – Why only these? Why not other REFERENCE occurrences?). The identified content from the alternate location substitutes for the REFERENCE and the result MUST be schema-valid. The transformation from REFERENCE content to in-line content is the only transformation directly defined by the model.“

It should be possible to persist the included content in a CMIS repository, and so we propose guidance how that may be done.

Note that REFERENCE also permits internal references, but Document Management Services does not address those.

The existing REFERENCE/LocationURL is “the URL where the resource may be found when the location is external to the current XML document”. In Document Management Services, we propose to use REFERENCE/LocationURL to represent the CMIS service endpoint (see CMIS 2.1). For example, the LocationURL for the test CMIS repository is http://cmis.alfresco.com:80/service/cmis/.

The CMIS standard permits one CMIS service endpoint to provide access to more than one CMIS repository. The MISMO V3 REFERENCE container has no element to express which of several CMIS repositories to access at the CMIS service endpoint, so in Document Management Services we propose a new data element REFERENCE/LocationRepositoryIdentifier for this. If there exists only one CMIS repository at the CMIS service endpoint, the REFERENCE/LocationRepositoryIdentifier is optional, and the single CMIS repository at the CMIS service endpoint is accessed.

The existing REFERENCE/LocationXPath is the “location of the resource within the external resource”. In Document Management Services, we propose to use REFERENCE/LocationXPath to represent the cmis:path property.

Note: In theory, the CMIS repository identifier could be appended to LocationURL, or prefixed to LocationXPath. We believe however that doing so is contrary to the CMIS standard. We believe that the CMIS repository identifier is a concept separate from the others.

Within the MISMO V3 model, REFERENCE occurs in locations where it makes sense for the content item itself to be located externally in a repository, including DOCUMENT. A REFERENCE may be a DEAL, DOCUMENT, FOREIGN_OBJECT, PARTY, TEMPLATE_FILE, and TRANSFORM_FILE. Further, because FOREIGN_OBJECT may be a REFERENCE, foreign objects like AUDIT_TRAIL_ENTRY_EVIDENCE, DOCUMENT_SET, ELECTRONIC_SIGNATURE, TEMPLATE_FILE, TEMPLATE_PAGE_FILE, TRANSFORM_FILE, TRANSFORM_PAGE_FILE, UNKNOWN_VERSION3_DOCUMENT, and VIEW_FILE may also be located externally in a repository. The primary difference between REFERENCE and FOREIGN_OBJECT is that REFERENCE contains data in MISMO's name space, and FOREIGN_OBJECT contains data in a foreign name space. Please see Appendix 2 for a more complete discussion of these concepts.

The last remaining element in the REFERENCE container is REFERENCE/OriginalCreatorDigestValue, an “optional placeholder for storing the original digest of the resource at the time of its creation. This value is a hash value of the referenced content stream, and it helps you to know when the content stream has changed. If you generate and save a hash value when you persist the content stream, and re-generate the hash value when you later access the content stream, you can compare the two hash values to know that the content stream has changed in the meantime. You do not need to do this when you expect the content stream to change, but you should do this when you expect the content stream to be unchanged. The REFERENCE/OriginalCreatorDigestValue is useful within the context of Document Management Services, but has no specific DMS meaning.

This DMS proposal section explains how to implement the MISMO V3 REFERENCE container so that external content may be saved in a CMIS repository. Why then do we call this section “Get document using REFERENCE”? It is because the MISMO model expects any application that encounters a REFERENCE container in a MISMO message to replace the REFERENCE container with the referenced content. In other words, “Get document using REFERENCE” is the expected behavior of any application that processes a MISMO message. When the referenced content is persisted in a CMIS repository, this involves accessing the CMIS repository, getting the content stream it finds there, and replacing the REFERENCE element with that content. That is in essence what a DMS “get document” service would do, were we to define a DOCUMENT_SET_SERVICE for this. REFERENCE requires this implicitly, as defined by the MISMO V3 model.

Proposed MISMO Model Changes

New Container: DOCUMENT_SET_SERVICES

DOCUMENT_SET_SERVICES is a set of services related to document sets, including uploads, downloads and searches. Each request and response may use data structures from the CMIS standard.

The MISMO V3.0 Candidate Recommendation released in May of 2010 contains a revised hierarchy at high levels in the MESSAGE tree. The BUNDLES container node has been replaced by DEAL_SETS, to better match DOCUMENT_SETS.

The DEAL_SETS container node contains a DEAL_SET_SERVICES node that is intended to provide data specific to services that act upon one or more of the contained DEAL_SET nodes, such as Loan Delivery services.

We propose to create a similar services container, called DOCUMENT_SET_SERVICES, for services that act upon one or more DOCUMENT_SET nodes under the DOCUMENT_SETS container.

Contents of DOCUMENT_SET_SERVICE

At this time we propose to support three services, DOWNLOAD, SEARCH and UPLOAD, with corresponding container nodes for each. Within each DOCUMENT_SET_SERVICE, only one choice is allowed.

Each of these service nodes will contain REQUEST and RESPONSE nodes, to be used as needed.

DOCUMENT_SET_DOWNLOAD

The purpose of the DOCUMENT_SET_DOWNLOAD service is to request the download of one or more documents, based upon the organization and capabilities of the repository being queried.

The DOCUMENT_SET_DOWNLOAD _REQUEST may contain criteria such as names and identifiers of either documents or containing folders. The DOCUMENT_SET_DOWNLOAD_RESPONSE may contain specific result status values for each of the requested items. We have yet to determine whether the returned content will be in the RESPONSE container, or as descendent nodes of DOCUMENT_SET.

CMIS_DOWNLOAD_REQUEST, CMIS_DOWNLOAD_RESPONSE and CMIS_XML

It is expected that the details of the download request and response will use CMIS-compliant structures. The purpose of the CMIS_XML complexType is to provide MISMO containers that accept any content in the CMIS namespace. Within the DOCUMENT_SET_DOWNLOAD node, CMIS_DOWNLOAD_REQUEST and CMIS_DOWNLOAD_RESPONSE use this type.

DOCUMENT_SET_SEARCH

The purpose of the DOCUMENT_SET_SEARCH service is to find a collection of documents in the repository, based upon given criteria. Some of the criteria may be specific to the repository being accessed, and some may refer to MISMO-related facts. It is yet to be determined how best to relate data within the MISMO namespace to the contents of a CMIS repository.

CMIS repositories support searches by providing a read-only SQL relational database view of the repository structure, and allowing simplified SQL SELECT queries to be made against that structure. When a query is submitted, a set of nodes representing CMIS objects (normally documents) is returned, containing the requested properties.

The DOCUMENT_SET_SEARCH _REQUEST may contain criteria such as names and identifiers of either documents or containing folders. It may also contain document metadata, such as the contents of DOCUMENT_CLASSIFICATION, DOCUMENT_SET_USES (see specification below), and facts about related PARTIES and LOANS. We have yet to determine how best to translate these values into the required SQL SELECT statement.

The DOCUMENT_SET_SEARCH_RESPONSE will contain a collection of CMIS objects that meet the specified criteria. Sufficient information should be returned in the result set to allow subsequent downloads to be performed to return the content of those documents. If related DEAL data and a corresponding set of RELATIONSHIPs were sent in the request, it may be possible to return a set of RELATIONSHIPs in the response that show how the returned objects are related to the DEAL data.

Our use cases assume that the results must be formatted and presented to a human actor, who then makes decisions about whether to make further queries or download document content.

CMIS_SEARCH_REQUEST, CMIS_SEARCH_RESPONSE and CMIS_XML

It is expected that the details of the search request and response will use CMIS-compliant structures. The purpose of the CMIS_XML complexType is to provide MISMO containers that accept any content in the CMIS namespace. Within the DOCUMENT_SET_SEARCH node, CMIS_SEARCH_REQUEST and CMIS_SEARCH_RESPONSE use this type.

DOCUMENT_SET_UPLOAD

The purpose of the DOCUMENT_SET_UPLOAD service is to send a collection of documents to the repository, together with sufficient information to define their location in the repository. The request should also allow the specification of metadata to allow for successful searches and downloads in the future. Some of the metadata may refer to MISMO-related facts. It is yet to be determined how best to relate data within the MISMO namespace to the contents of a CMIS repository.

The DOCUMENT_SET_UPLOAD_REQUEST will contain sufficient information to identify the name and location within the repository for the collection of documents to be uploaded. A RELATIONSHIP node will point the parent DOCUMENT_SET_SERVICE container to the DOCUMENT_SET which contains the document content to be uploaded.

The DOCUMENT_SET_UPLOAD_RESPONSE will contain the one or more status values that may report on the success of uploading the DOCUMENT_SET. The details and complexity of the returned values will depend upon the implementation.

CMIS_UPLOAD_REQUEST, CMIS_UPLOAD_RESPONSE and CMIS_XML

It is expected that the details of the upload request and response will use CMIS-compliant structures. The purpose of the CMIS_XML complexType is to provide MISMO containers that accept any content in the CMIS namespace. Within the DOCUMENT_SET_UPLOAD node, CMIS_UPLOAD_REQUEST and CMIS_UPLOAD_RESPONSE use this type.

New Container: DOCUMENT_SET_DETAIL

Document Management Services will support uploading and filing documents into folders, so the MISMO V3 model must provide a way to express CMIS' folder properties. We can use DOCUMENT_SET_DETAIL to do this. This differs conceptually from how DMS expresses document properties. For document properties, generally the property values (name, creation date) are different for every document, even for the same type of document, and so we chose to express document properties in the DOCUMENT_CLASSIFICATION_DETAIL container within DOCUMENT. Generally, however, the folder or folders in which a document is filed do not depend on the specific document instance, but only on the type of document it is. For example, you may want to file all of your Notes in one folder, but you probably wouldn't have a different folder for every note. The whole point to folders is to help organize documents, and having a different folder for every document does not help with organization. Therefore, folder properties should be expressed outside of the individual document, and we choose the DOCUMENT_SET_DETAIL container, as shown below.

DocumentSetDescription is a human-readable description of the collection of documents, and has no CMIS equivalent. DocumentSetFolderName is the name of the folder in which the documents are or should be filed, and corresponds to the cmis:name folder property. DocumentSetFolderLocationURI is a URI where the DocumentSetFolderName folder is located, and corresponds to the cmis:path folder property. The DOCUMENT_SET_DETAIL values apply to all documents in the set.

Alternate new container: DOCUMENT_SET_FOLDER

Note: here is an alternative to DOCUMENT_SET_DETAIL, named DOCUMENT_SET_FOLDER. This assumes that we have no other details to assign to DOCUMENT_SET, and that there is a choice to either use MISMO terms or CMIS terms.

On the other hand, if we decide that DocumentSetDescription has value with or without folder information, it could become the (so far) only child of a DOCUMENT_SET_DETAIL container in addition to the DOCUMENT_SET_FOLDER container shown below.

New Container: DOCUMENT_SET_USES

There are multiple ways that documents and collections of documents can be classified. One way, currently covered by the DOCUMENT_CLASSIFICATION container, is by identifying and describing those characteristics that distinguish a document from another. A new container, DOCUMENT_SET_USES, can classify and organize documents by how they are intended to be used. (How they actually were used is better described using DOCUMENT/AUDIT_TRAIL.)

Documents can have multiple uses, and a particular use may involve multiple documents, so the relationship is many-to-many. For example, a collection of pay stub documents may be used once by an origination process, and a second time by a loan modification process.

The DocumentSetUseCode is a data point than holds a code value that is meaningful to the owner of the use or process it describes. As a MISMOCode, it also has a CodeOwnerURI attribute to identify the owner. The DocumentUseDescription is a free-form description of the use and/or process.

Note that a CMIS repository implementation may use folders to organize document sets by their uses. The CMIS standard supports a multi-filing capability which allows a single document to belong to multiple folders. We believe that the DOCUMENT_SET_USES structure will allow us to describe the usage explicitly, independent from the folder hierarchy.

Updated Container: DOCUMENT_CLASSIFICATION_DETAIL

The table below shows how to represent CMIS document properties in the MISMO V3.x model, which is necessary to support MISMO Document Management Services. The “MISMO V3.x...” column shows that this DMS proposal places CMIS document properties into DOCUMENT_CLASSIFICATION_DETAIL, which contains “non-repeatable information about a specific instance of a document.” Three elements (ObjectName, ObjectCreatedDatetime, and MIMETypeIdentifier) are already MISMO LDD data points from the FOREIGN_OBJECT container which we re-use here, but the majority are new to MISMO. All of the new elements use the “CMIS” acronym prefix which we have proposed elsewhere to be added to MEG0008. The CMIS prefix indicates that while the elements are in MISMO's namespace, their semantics are controlled by the CMIS specification. This is similar to how the model already uses “FNM” and “FRE” as element name prefixes to indicate Fannie Mae and Freddie Mac are the controlling entity.

 

CMIS document property	CMIS property definition	CMIS Type	MISMO V3.x mapping
cmis:name	Name of the object	String	DOCUMENT_CLASSIFICATION_DETAIL/ObjectName
cmis:objectId	Id of the object	ID	DOCUMENT_CLASSIFICATION_DETAIL/CMISObjectIdentifier
cmis:baseTypeId	Id of the base object-type for the object	ID	DOCUMENT_CLASSIFICATION_DETAIL/CMISBaseTypeIdentifier
cmis:objectTypeId	Id of the object’s type	ID	DOCUMENT_CLASSIFICATION_DETAIL/CMISObjectTypeIdentifier
cmis:createdBy	User who created the object.	String	DOCUMENT_CLASSIFICATION_DETAIL/CMISCreatedByName
cmis:creationDate	DateTime when the object was created.	DateTime	DOCUMENT_CLASSIFICATION_DETAIL/ObjectCreatedDatetime
cmis:lastModifiedBy	User who last modified the object.	String	DOCUMENT_CLASSIFICATION_DETAIL/CMISLastModifiedByName
cmis:lastModificationDate	DateTime when the object was last modified.	DateTime	DOCUMENT_CLASSIFICATION_DETAIL/CMISLastModificationDatetime
cmis:changeToken	Opaque token used for optimistic locking & concurrency checking.	String	DOCUMENT_CLASSIFICATION_DETAIL/CMISChangeTokenString
cmis:isImmutable	TRUE if the repository MUST throw an error at any attempt to update or delete the object.	Boolean	DOCUMENT_CLASSIFICATION_DETAIL/CMISIsImmutableIndicator
cmis:contentStreamLength	Length of the content stream (in bytes).	Integer	DOCUMENT_CLASSIFICATION_DETAIL/CMISFileLengthCount
cmis:contentStreamMimeType	MIME type of the Content Stream	String	DOCUMENT_CLASSIFICATION_DETAIL/MIMETypeIdentifier
cmis:contentStreamFileName	File name of the Content Stream	String	DOCUMENT_CLASSIFICATION_DETAIL/CMISFileName
cmis:contentStreamID	Id of the stream	ID	DOCUMENT_CLASSIFICATION_DETAIL/CMISFileIdentifier

 

Appendices

Appendix 1: CMIS Repository Requirements

The intent of the MISMO Document Management Services project is to enhance the MISMO V3.x model to support document management services upon document repositories. The DMS project has chosen to use the Content Management Interoperability Services standard as the representation of a content repository, because CMIS already standardizes many of the services we want the DMS project to expose within the MISMO model.

To promote interoperability, it is not enough just to modify the MISMO V3 model alone. Interoperability demands that any MISMO DMS client be able to work with any MISMO DMS repository. Therefore it may be that there are requirements upon CMIS client applications and repositories that go beyond the minimum conformance level specified by the CMIS 1.0 standard. This appendix addresses CMIS repository requirements for use within MISMO DMS services that are in addition to the minimum CMIS repository standards.

The CMIS Change Log and MISMO Audit Trails

This DMS proposal includes guidance regarding how to implement the CMIS change log feature in a manner that is compatible with MISMO V3.

A MISMO V3 document includes a container element called AUDIT_TRAIL in which each audit trail entry is comprised of the following elements.

 

EntryDateTime	MISMODatetime	The date and time the action occurred. The time must always contain the proper time zone designator.
EntryDescription	MISMOString	Contains additional information or details about the action performed.
EntryType	EntryTypeEnumerated	Contains the type of the action performed.
EntryTypeOtherDescription	MISMOString	Contains a description of the type of action performed when the value of Other is used for EntryType.
PerformedByOrganizationName	MISMOString	Contains the name of the organization that performed the action.
PerformedBySystemEntryIdentifier	MISMOIdentifier	Contains an identifier that was assigned by the system that performed the action.
PerformedBySystemName	MISMOString	Contains the name of the system used for performing the action.

The EntryType of each MISMO V3 document audit trail entry is one of the following list of values, which represent events that occur to the document.

EntryTypeEnumerated	Contains the type of the action performed.
AddedTaxCollectionStamps
CorrectedData
CreatedBlankDocument	Denotes that the document boiler plate has been created. The view is unpopulated and there are no data parts. A SMART Doc® document must contain exactly one audit entry with this action type.
DocumentReceived
DraftedData	Denotes that draft data has been added to the document or that a previous set of draft data has been modified. A SMART Doc® document may contain zero or more audit entries with this action type
EnteredData
ExportedDocument	Denotes that the document has been exported to a different electronic format, but the SMART Doc® document is still in effect.
NotarizedDocument
Other	Denotes that the action type is other than the ones listed above. When this option is selected, a description of the action type must be provided in the ActionTypeOtherDescription attribute.
PaperedOutDocument	Denotes that the SMART Doc® document has been converted to paper form and that the electronic version no longer has legal force or effect. A SMART Doc® document must not contain more than one audit entries with this action type.
PartiallyPopulatedDocument
PopulatedDocument	Denotes that the document has been populated with data. The data appears in the original view and may also be present in one or more data parts. A SMART Doc® document must not contain more than one audit entries with this action type.
RecordedDocument	Denotes that the document has been recorded.
RerecordedDocument
SignedDocument	Denotes that a principal party, a witness or a notary has signed the document. A SMART Doc® document may contain zero or more audit entries with this action type.
ValidatedDocument	Denotes that a system or process has validated the provided data parts against the corresponding readable data in the presentation view. A SMART Doc® document may contain zero or more audit entries with this action type.
VerifiedSignatures	Denotes that a system or process has verified that all required signatures for all stakeholder parties, notaries and witnesses have been executed. The document is fully executed.
VoidedDocument	Denotes that the document no longer has legal force or effect. A SMART Doc® document must not contain more than one audit entries with this action type.

A CMIS repository provides a change log (http://docs.oasis-open.org/cmis/CMIS/v1.0/os/cmis-spec-v1.0.html#_Toc243905424) which is similar in purpose to MISMO's document audit trail. Both the CMIS repository change log and a MISMO V3 document audit trail record “change events”, which are actions that change the state of documents. The primary difference between them is that CMIS change events record repository changes, but MISMO audit trail entries record document changes. This difference is not an issue in practice: A CMIS repository change log contains any document's change events, so you can produce MISMO's document audit trail by selecting only the repository change events that occurred to that document.

In addition, the CMIS repository change log supports additional use cases that MISMO's document audit trail does not. For example, the CMIS repository change log records non-document change events that MISMO's audit trail does not capture, such as when a document is moved from folder to folder, or when document access permissions change. In all, the CMIS repository change log is more complete than MISMO's document audit trail, and the MISMO document audit trail can be created from CMIS repository change log events.

The major shortcoming of the CMIS change log relative to MISMO's document audit trail is that the CMIS change log provides less detail than MISMO's document audit trail requires. The CMIS change log specification is general to document management applications, and MISMO's document audit trail is specific to mortgage lending document management use cases. For example, the CMIS specification says only that the change log entries must record when a document is created, updated, and deleted, or when its access permissions change. This is not nearly the level of detail required by the MISMO document audit trail, which must record all of the document events shown in the table above.. Therefore this DMS proposal shows how to implement the CMIS change log so that it provides all of the detail the MISMO model requires. It is important that this proposal include this guidance so that all MISMO DMS implementers use CMIS repositories interoperably. Because many parties may use the same CMIS document repository, no single client on its own can know all of the activities that occur on documents therein. Only the CMIS repository can implement the change log, so it makes little sense for CMIS clients to do so. But if MISMO DMS clients rely on the CMIS repository to maintain the audit log, then CMIS repository change log requirements that go beyond the minimum for CMIS conformance must be spelled out clearly and implemented uniformly.

Note: CMIS-compliant repositories can have different levels of change log completeness. A compliant repository 1) may be able to return a change entry for every change ever made to a document, or it 2) may only be able to return a change entry for all changes made since a particular point in time. This DMS proposal assumes the CMIS repository change log provides a complete list of change entries.

The CMIS “created” change type is the same as the MISMO “CreatedBlankDocument” audit log entry type. There will be only one of either of these per document.

The CMIS “deleted” and “security” change types currently have no MISMO audit log entry type equivalents.

The CMIS “updated” change type is used for all other MISMO audit log entry types. CMIS “updated” change events include a list of changed CMIS document properties. To be able to reconstruct a MISMO audit log entry from a CMIS change event, all of the MISMO audit log elements must be included as document properties in the CMIS change event. For interoperability, these must be named consistently in the CMIS repository. We propose these CMIS document property names. These are simply the MISMO audit trail entry element names from above, with the MISMO name space prefix.

mismo:EntryDateTime

mismo:EntryDescription

mismo:EntryType

mismo:EntryTypeOtherDescription

mismo:PerformedByOrganizationName

mismo:PerformedBySystemEntryIdentifier

mismo:PerformedBySystemName

Applications that wish to use the CMIS change log to manage MISMO audit trail entries must configure the CMIS repository to add the above CMIS document properties. Further, the CMIS client application must ensure that these property values are correctly maintained.