Content Management Interoperability Services (CMIS) Version 1.0 Errata 01

Committee Specification Draft 01 /
Public Review Draft 01

11 March 2011

Specification URIs:

This version:

http://docs.oasis-open.org/cmis/CMIS/v1.0/errata-01/csprd01/cmis-spec-v1.0-errata-01-csprd01.doc (Authoritative)
http://docs.oasis-open.org/cmis/CMIS/v1.0/errata-01/csprd01/cmis-spec-v1.0-errata-01-csprd01.html
http://docs.oasis-open.org/cmis/CMIS/v1.0/errata-01/csprd01/cmis-spec-v1.0-errata-01-csprd01.pdf

Previous version:

N/A       

Latest version:

http://docs.oasis-open.org/cmis/CMIS/v1.0/errata-01/cmis-spec-v1.0-errata-01.doc (Authoritative)

http://docs.oasis-open.org/cmis/CMIS/v1.0/errata-01/cmis-spec-v1.0-errata-01.html
http://docs.oasis-open.org/cmis/CMIS/v1.0/errata-01/cmis-spec-v1.0-errata-01.pdf

 

Technical Committee:

OASIS Content Management Interoperability Services (CMIS) TC

Chair:

David Choy, EMC

Editors:

Ryan McVeigh, Zia Consulting

Florian Müller, Alfresco

Related work:

This specification is related to:

·         OASIS Standard Content Management Interoperability Services (CMIS) Version 1.0

Declared XML Namespaces:

http://docs.oasis-open.org/ns/cmis/core/200908/

http://docs.oasis-open.org/ns/cmis/restatom/200908/

http://docs.oasis-open.org/ns/cmis/messaging/200908/

http://docs.oasis-open.org/ns/cmis/ws/200908/

http://docs.oasis-open.org/ns/cmis/link/200908/

Abstract:

This document lists approved errata to the CMIS V1.0 OASIS Standard.

Status:

This document was last revised or approved by the OASIS Content Management Interoperability Services (CMIS) TC on the above date. The level of approval is also listed above. Check the “Latest Version” location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/cmis/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/cmis/ipr.php).

 

Citation format:

When referencing this specification the following citation format should be used:

[CMIS-v1.0-errata-1]

Content Management Interoperability Services (CMIS) Version 1.0 Errata 01. 11 March 2011. OASIS Committee Specification Draft 01 / Public Review Draft 01. http://docs.oasis-open.org/cmis/CMIS/v1.0/errata-01/csprd01/cmis-spec-v1.0-errata-01-csprd01.doc

 

Notices

Copyright © OASIS Open 2011. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The names "OASIS" and “CMIS” are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

 

Table of Contents

1        Introduction. 5

1.1 Normative References. 5

2        Approved Errata. 6

2.1 CMIS-534: getAllowableActions Service output seems to restrict to XML based bindings. 6

2.2 CMIS-537: getRenditionsExceptions – filterNotValid is overloaded. 6

2.3 CMIS-564: createDocumentFromSource versioningState param needs clarification. 8

2.4 CMIS-641: applyACLResponse does not match domain model - no changeToken. 8

2.5 CMIS-646: cmis:objectTypeId should not be required for documents. 8

2.6 CMIS-647: ACL propagation in ACL capabilities is supposed to be an array. 9

2.7 CMIS-648: AllowableActions keys inconsistencies. 9

2.8 CMIS-650: change atom:id reference from URI to IRI 11

2.9 CMIS-651: Clarify that URI templates are to be used with GET. 12

2.10 CMIS-656: Clarify how ETags and cmis:changeToken interact 12

2.11 CMIS- 657: Clarify cancelCheckout's proper behavior when doc was created in a checked out state. 12

2.12 CMIS-659: Clarification for properties in state "not set" required. 12

2.13 CMIS-663: localName for type definition is optional according to domain model but is required according to core.xsd schema. 13

2.14 CMIS-674: Change BNF comment to !! style comment 13

2.15 CMIS-687: cmis:changeToken should not be mandatory if the repository doesn't support change tokens  13

2.16 CMIS-688: Query sample incorrect 14

2.17 CMIS-689: invalid property name cmis:createdDate referenced in 3.5.2. 14

2.18 CMIS-690: cmis:versionLabel cardinality not specified. 15

2.19 CMIS-695: Escaping section should specify which BNF symbols it applies to. 15

2.20 CMIS-697: Word plus phrase example for CONTAINS query. 16

2.21 CMIS-706: Domain model should state objects are not constrained. 16

A.      Acknowledgements. 17

B.      Revision History. 19

 

 

 


1      Introduction

This document lists the approved errata to the CMIS v1.0 OASIS Standard. Each one has a number that refers to the issue that triggered the erratum.

As required by the OASIS Technical Committee Process, the approved errata represent changes that are not “substantive”. The changes focus on clarifications to ambiguous or conflicting specification text, where different compliant implementations might have reasonably chosen different interpretations. The intent of the CMIS TC has been to resolve such issues in service of improved interoperability based on implementation and deployment experience.

In this document, errata change instructions are presented with surrounding context as necessary to make the intent clear. Original specification text is often presented as follows, with problem text highlighted in bold:

This is an original specification sentence. The second sentence needs to be changed, removed, or replaced.

New specification text is typically presented as follows, with new or changed text highlighted in bold:

This is a highly original specification sentence. This is the wholly new content to replace the old second sentence. It runs on and on and on.

In a few cases, text needs only to be struck, in which case the change is shown as follows, with text to be removed both highlighted in bold and struck through:

This is yet another original specification sentence which contains an inappropriately long description.

In addition to this normative document, non-normative “errata composite” documents may be provided that combine the prescribed corrections with the original specification text, illustrating the changes with margin change bars, struck-through original text, and highlighted new text. These documents, if available, will be found at the same location as this approved form.

All cited line numbers refer to the Word document of the original OASIS Standard specifications in question, not to line numbers in this document or in the errata composite documents.

 

1.1 Normative References

 

[CMIS1.0]         CMIS v1.0 OASIS Standard, http://docs.oasis-open.org/cmis/CMIS/v1.0/os/cmis-spec-v1.0.doc, May 2010

 

2      Approved Errata

Following are the approved errata to the CMIS v1.0 OASIS Standard.

2.1 CMIS-534: getAllowableActions Service output seems to restrict to XML based bindings

Change Section 2.2.1.2.6 at line 2853.

Original:

  • AllowableActions: See cmisAllowableActionsType in the CMIS schema.

New:

·         <Array> AllowableActions: The list of allowable actions for the object.

2.2 CMIS-537: getRenditionsExceptions – filterNotValid is overloaded

Change Section 2.2.3.1.3 at line 3206-3207.

Original:

·          filterNotValid: The Repository MUST throw this exception if this property filter input parameter is not valid.

New:

·         filterNotValid: The Repository MUST throw this exception if the property or rendition filter input parameter is not valid.

Change Section 2.2.3.2.3 at line 3249-3250.

Original:

·         filterNotValid: The Repository MUST throw this exception if this property filter input parameter is not valid.

New:

·         filterNotValid: The Repository MUST throw this exception if the property or rendition filter input parameter is not valid.

Change Section 2.2.3.3.3 at line 3288-3289.

Original:

·         filterNotValid: The Repository MUST throw this exception if this property filter input parameter is not valid.

New:

·         filterNotValid: The Repository MUST throw this exception if the property or rendition filter input parameter is not valid.

Change Section 2.2.3.5.3 at line 3337-3338.

Original:

·         filterNotValid: The Repository MUST throw this exception if this property filter input parameter is not valid.

New:

·         filterNotValid: The Repository MUST throw this exception if the property or rendition filter input parameter is not valid.

Change Section 2.2.3.6.3 at line 3438.

Original:

·         filterNotValid: The Repository MUST throw this exception if this property filter input parameter is not valid.

New:

·         filterNotValid: The Repository MUST throw this exception if the property or rendition filter input parameter is not valid.

Change Section 2.2.4.7.3 at line 3643-3644.

Original:

·         filterNotValid: The Repository MUST throw this exception if this property filter input parameter is not valid.

New:

·         filterNotValid: The Repository MUST throw this exception if the property or rendition filter input parameter is not valid.

Change Section 2.2.4.9.3 at line 3677-3678.

Original:

·         filterNotValid: The Repository MUST throw this exception if this property filter input parameter is not valid.

New:

·         filterNotValid: The Repository MUST throw this exception if the property or rendition filter input parameter is not valid.

Change Section 2.2.4.11.3 at line 3717.

Original:

  • filterNotValid : The filter specified is not valid

New:

  • filterNotValid : The rendition filter specified is not valid

Change Section 2.2.7.4.3 at line 4103-4104.

Original:

·          filterNotValid: The Repository MUST throw this exception if this property filter input parameter is not valid.

New:

·         filterNotValid: The Repository MUST throw this exception if the property or rendition filter input parameter is not valid.

2.3 CMIS-564: createDocumentFromSource versioningState param needs clarification

Change section 2.2.4.2.1 at lines 3455-3456.

Original:

·          Enum versioningState: An enumeration specifying what the versioing state of the newly-created object MUST be. Valid values are:

New:

·         Enum versioningState: An enumeration specifying what the versioning state of the newly-created object MUST be. If the repository does not support versioning, the repository MUST ignore the versioningState parameter.  Valid values are:

2.4 CMIS-641: applyACLResponse does not match domain model - no changeToken

Change section 2.2.10.2.2 at line 4279.

New:

  • String changeToken: See section 2.2.1.3.

2.5 CMIS-646: cmis:objectTypeId should not be required for documents

Change section 2.1.5.4.2 at line 1190.

Original:

Required:                                                     False

New:

Required:                                                     True

Change section 2.1.6.1.3 at line 1427.

Original:

Required:                                                     False

New:

Required:                                                     True

Change section 2.1.7.1.2 at line 1649.

Original:

Required:                                                     False

New:

Required:                                                     True

2.6 CMIS-647: ACL propagation in ACL capabilities is supposed to be an array

Change section 2.1.8.3 at lines 1744-1745.

New:

  • <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):

Change section 2.1.8.3 at lines 1748-1749.

Original:

    • propagate: indicates that the ACEs is to be applied to the given object and all inheriting objects.

New:

    • propagate: indicates that the ACEs is to be applied to the given object and all inheriting objects. Propagate incorporates the support for objectonly.

2.7 CMIS-648: AllowableActions keys inconsistencies

Change section 2.1.8.3.1 at lines 1813-1818.

New:

canGetFolderTree

Description:                  Can get the sub-folder tree of the folder (getFolderTree)

Base Object:                 cmis:folder

Operand:                       cmis:folder

Key:                              canGetFolderTree.Folder

Permission:                   Read

Change section 2.1.8.3.1 at line 1831.

Original:

Key:                              canGetFolderParent.Folder

New:

Key:                              canGetFolderParent.Object

Change section 2.1.8.3.1 at line 1838.

Original:

Key:                              canGetObjectParents.Object

New:

Key:                              canGetParents.Object

Change section 2.1.8.3.1 at lines 1880-1885.

New:

canGetRenditions

Description:                  Can retrieve the renditions of this object (getRenditions)

Base Object:                 cmis:document, or cmis:folder

Operand:                       Object

Key:                              canGetRenditions.Object

Permission:                   Read

Change section 2.1.8.3.1 at lines 1887-1893.

New:

canGetContentStream

Description:                  Can get the content stream for the Document object (getContentStream)

Base Object:                 cmis:document

Operand:                       Object

Key:                              canGetContentStream.Object

Permission:                   Read

Change section 2.1.8.3.1 at line 1913.

Original:

Key:                              canMoveObject.Target

New:

Key:                              canMove.Target

Change section 2.1.8.3.1 at line 1920.

Original:

Key:                              canMoveObject.Source

New:

Key:                              canMove.Source

Change section 2.1.8.3.1 at lines 1930-1935.

New:

canDeleteObject

Description:                  Can delete an object that is a child of this folder (deleteObject)

Base Object:                 cmis:folder

Operand:                       Folder

Key:                              canDelete.Folder

Permission:                   Read

Change section 2.1.8.3.1, add after line 1935.

New:

canGetContentStream

Base Object:                 cmis:document

Action:                          Can get the content stream for the Document object (getContentStream)

Operand:                       Object

Key:                              canViewContent.Object

Permission:                   Read

Change section 2.1.8.3.1 at line 1942.

Original:

Key:                              canSetContentStream.Document

New:

Key:                              canSetContent.Document

Change section 2.1.8.3.1 at line 1950.

Original:

Key:                              canDeleteContentStream.Document

New:

Key:                              canDeleteContent.Document

Change section 2.1.8.3.1 at line 1980.

Original:

Key:                              canRemoveObjectFromFolder.Object

New:

Key:                              canRemoveFromFolder.Object

Change section 2.1.8.3.1 at line 1996.

Original:

Key:                              canCheckOut.Document

New:

Key:                              canCheckout.Document

Change section 2.1.8.3.1 at line 2017.

Original:

Key:                              canGetAllVersions.Document

New:

Key:                              canGetAllVersions.VersionSeries

2.8 CMIS-650: change atom:id reference from URI to IRI

Change section 3.5.1 at lines 5130-5131.

Original:

  • atom:id SHOULD be derived from cmis:objectId.  This id MUST be compliant with atom’s specification and be a valid URI.

New:

  • atom:id SHOULD be derived from cmis:objectId.  This id MUST be compliant with atom’s specification and be a valid IRI.

2.9 CMIS-651: Clarify that URI templates are to be used with GET

Change section 3.6.1, add after line 5361.

New:

URI Templates MUST only be used with HTTP GET.

2.10 CMIS-656: Clarify how ETags and cmis:changeToken interact

Change section 3.2.1, add after line 4402.

New:

On updates, perform the following checks (HTTP & CMIS levels):

 

  1. If If-Match header is sent by client, ETag value is pulled from HTTP header If-Match per RFC2616. The supplied ETag is compared against the ETag on the server. If the match fails, then status code 412 is used.

 

  1. If cmis:changeToken property is supplied by the client, compare the supplied and the cmis:changeToken on the server. If the comparison fails, then return status code 409 per CMIS.

 

  1. If ETag and cmis:changeToken are both specified, the HTTP If-Match check should be performed first.

2.11 CMIS- 657: Clarify cancelCheckout's proper behavior when doc was created in a checked out state.

Change section 2.2.4.1.1 at line 3395.

Original:

  • checkedout: The document MUST be created in the checked-out state.

New:

  • checkedout: The document MUST be created in the checked-out state. The checked-out document MAY be visible to other users.

Change section 2.2.7.2 at lines 4023-4024.

Original:

Description: Reverses the effect of a check-out. Removes the private working copy of the checked-out document, allowing other documents in the version series to be checked out again.

New:

Description: Reverses the effect of a check-out. Removes the private working copy of the checked-out document, allowing other documents in the version series to be checked out again. If the private working copy has been created by createDocument, cancelCheckOut MUST delete the created document.

2.12 CMIS-659: Clarification for properties in state "not set" required

Change section 2.1.2.1 at lines 218-223.

Original:

If a value is not provided for a 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 not set, or is set to a particular value or a list of values.

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.

New:

A property, either single-valued or multi-valued, MAY be in a "not set" state. CMIS does not support "null" property value.

If a multi-valued property is not in a "not set" state, its property value MUST be a non-empty list of individual values. Each individual value in the list MUST NOT be in a "not set" state and MUST conform to the property's property-type.

Change section 2.2.1.2.1 at lines 2784-2785.

Original:

If a property filter specifies a property that is ‘not set’, it MUST be represented as a property element without a value element.

New:

If a property is requested by a filter, a property element MUST be returned for that property. A repository MAY return additional properties. If a returned property is in a "not set" state, a value element MUST NOT be returned for that property.

2.13 CMIS-663: localName for type definition is optional according to domain model but is required according to core.xsd schema

Change section 2.1.3.2.1 at line 327 to match the CMIS schema.

New:

localName         String (optional)

2.14 CMIS-674: Change BNF comment to !! style comment

Change section 2.2.1.2.4.1 at line 2826.

Original:

<text> ::= /* any char except whitespace */

New:

<text> ::= !! any char except whitespace

2.15 CMIS-687: cmis:changeToken should not be mandatory if the repository doesn't support change tokens

Change section 2.1.4.3.3 at lines 845-846.

Original:

Repository MUST return this property with non-empty values when an object is requested and the property filter does not exclude them

New:

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.

Change section 2.1.5.4.2 at lines 1260-1261.

Original:

Repository MUST return this property with non-empty values when an object is requested and the property filter does not exclude them

New:

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.

Change section 2.1.6.1.3, add after line 1511.

New:

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.

Change section 2.1.7.1.2, add after line 1701.

New:

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.

2.16 CMIS-688: Query sample incorrect

Change section 2.1.10.2.4.2.2 at line 2549-2551.

Original:

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 )

New:

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 )

2.17 CMIS-689: invalid property name cmis:createdDate referenced in 3.5.2

Change section 3.5.2 at lines 5157-5159.

Original:

  • app:edited MUST be cmis:lastModifiedDate
  • atom:updated MUST be cmis:lastModifiedDate
  • atom:published MUST be cmis:createdDate

New:

  • app:edited MUST be cmis:lastModificationDate
  • atom:updated MUST be cmis:lastModificationDate
  • atom:published MUST be cmis:creationDate

2.18 CMIS-690: cmis:versionLabel cardinality not specified

Change section 2.1.4.3.3, add after line 903.

New:

Cardinality:                    Single

2.19 CMIS-695: Escaping section should specify which BNF symbols it applies to

Replace entire section 2.1.10.3 at lines:  2676-2681.

Original:

Repositories MUST support the escaping of characters using a backslash (\) in the query statement.  The backslash character (\) will be used to escape characters within quoted strings in the query as follows:

  1. \’ will represent a single-quote(‘) character
  2. \ \ will represent a backslash (\) character
  3. Within a LIKE string, \% and \_ will represent the literal characters % and _, respectively.
  4. All other instances of a \ are errors.

New:

Character escaping for character strings differs from SQL-92's escaping. A repository MUST support the escaping of certain literal characters in a character string, or in a text expression, using a backslash character (\) in the following manner.  For a <character string literal>, which MUST BE a string enclosed in single-quotes according to the SQL-92 grammar, any occurrence of the single-quote character (') and the escape character (\) in the string MUST BE escaped. This applies to <folder id>, which is a <character string literal>. Furthermore, when a <character string literal> is used in a LIKE predicate, any occurrence of the percent character (%) and the underscore character (_) in the string as a literal MUST BE escaped also. Therefore, within a quoted string in a query:

  • The double character \' represents a literal single-quote (') character.
  • The double character \ \ represents a literal backslash (\) character.
  • Within a LIKE string, the double characters \% and \_ represent a literal percent (%) character and a literal underscore (_) character respectively.
  • All other instances of a backslash (\) character are errors.

Using double single-quotes ('') as a SQL-92 way to escape a literal single-quote (') character SHOULD BE supported as an allowable alternative to the double character \'.

 

For a <text search expression>, a second-level character escaping is required so that the <text search expression> sub-grammar is isolatable from the query statement-level grammar. When a text search expression is composed for a query according to the <text search expression> sub-grammar, any occurrence of the following three characters in the expression as a literal character MUST BE escaped: hyphen (-), single-quote ('), and the escape character (\). Then, before this expression is enclosed in single-quotes and inserted into a CONTAINS() predicate, the query statement-level escaping rules described in the above MUST BE applied. This two-level character escaping allows a query statement parser, using statement-level escaping rules, to correctly extract a <text search expression> as a character string literal independent of the <text search expression> sub-grammar. This extracted <text search expression> can then be correctly interpreted by a full-text search parser independent of the query-statement grammar, using second-level escaping rules. Since the <text search expression> sub-grammar is isolated from the SQL-92 grammar, double single-quotes is not a valid way to escape a literal single-quote character for second-level character escaping.

 

An <identifier> in a query statement MUST conform to the SQL-92 identifier syntax, and MUST NOT require character escaping.

 

Example 1:
A query statement that contains a full-text search for the literal string "John'sPresentation-Version2" may be composed as:

SELECT … FROM … WHERE … CONTAINS('John\\\'sPresentation\\-Version2') …

A query parser extracts from this statement the text search expression "John\'sPresentation\-Version2" as a character string literal, and passes it to a text-search parser, which interprets it as a single-word full-text search criteria: John'sPresentation-Version2.

 

Example 2:

A query statement that contains a full-text search for the phrase "Content Management" may be composed as:

SELECT … FROM … WHERE … CONTAINS('\'Content Management\'') …

A query parser extracts from this statement the text search expression "'Content Management'" as a character string literal, and passes it to a text-search parser, which interprets it as a full-text search criteria consisting of a single phrase: Content Management. There is no second-level escaping.

2.20 CMIS-697: Word plus phrase example for CONTAINS query

Replace section 2.1.10.3.  The same changes for CMIS-695.

2.21 CMIS-706: Domain model should state objects are not constrained

Add to section 2.1.2 following line 212.

New:

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.

 

A.  Acknowledgements

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

 

Participants:

Michael Duerig, Adobe Systems

David Nuescheler, Adobe Systems

Peeter Piegaze, Adobe Systems

Craig Randall, Adobe Systems

Angela Schreiber, Adobe Systems

Philippe Allart, Adullact

Betsy Fanning, AIIM

David Caruana, Alfresco Software

Florian Mueller, Alfresco Software

John Newton, Alfresco Software

Celso Rodriguez, ASG Software Solutions

Patrick Ward, Booz Allen Hamilton*

Steffen Frederiksen, Content Technologies ApS

Alpesh Patel, Ektron*

David Choy, EMC Corporation

Cornelia Davis, EMC Corporation

Norrie Quinn, EMC Corporation

Raphael Jean, Entropysoft

Hareesh Kadlabalu, FatWire

Derek Chow, Genus Technologies, LLC

Randy Dufault, Genus Technologies, LLC

Thomas Pole, Harris Corp

David Churchland, Hewlett-Packard*

Andrew Ewing, Hewlett-Packard*

Jay Brown, IBM

Derek Carr, IBM

Jane Doong, IBM

Scott Malabarba, IBM

Gregory Melahn, IBM

Patrick Ryan, IBM

Scott Conroy, Individual

Gershon Janssen, Individual

Mark Klamerus, Individual

Paolo Garroni, ISIS Papyrus America Inc.

Ethan Gur-esh, Microsoft Corporation

Adam Harmetz, Microsoft Corporation

Neil Joyer, Microsoft Corporation

Pat Miller, Microsoft Corporation

Florent Guillaume, Nuxeo

Jens Huebel, Open Text Corporation

Mark Carlson, Oracle Corporation

Eric Chan, Oracle Corporation

Alison Macmillan, Oracle Corporation

David Pitfield, Oracle Corporation

Steve Roth, Oracle Corporation

Paul Goetz, SAP AG*

Martin Hermes, SAP AG*

Stephan Klevenz, SAP AG*

Paul Tazbaz, Wells Fargo*

Alexander Haag, WeWebU Software AG

James Michel, WeWebU Software AG

Rainer Pausch, WeWebU Software AG

Ryan McVeigh, Zia Consulting, Inc.

B.  Revision History

 

Revision

Date

Editor

Changes Made

1.0

10/15/2010

Florian Müller

First draft