loading table of contents...

Content Server Manual / Version 2107

Table Of Contents

4.1 Properties

Each content type needs a specification of all properties that the corresponding content items have. The properties, presented as fields to the editor, vary, for example simple strings (such as for the author), XML for the textual content or binary data for graphics. This is determined in the content definition type with appropriate property types.



A content type may contain a maximum of 91 properties.

All field types have the attribute Name, defining the name by which the field can be referenced in an item.



The name can have a maximum length of 18 characters (DateProperty field names only 15 characters) and must not contain umlauts or other special characters ("§", "&", ...). Two fields in a content type different only in upper or lower case are not allowed. Furthermore, a name's last character must not be an underscore, since these field names are reserved for CoreMedia.

The property types are:

  • IntProperty

  • StringProperty

  • DateProperty

  • XmlProperty

  • BlobProperty

  • LinkListProperty

When defining XML elements and attributes in the following sections, the default namespace is assumed to be and the namespace prefix extensions is assumed to be bound to the namespace URL

Common Attributes

You can add the following attributes to each property:

Property Description


If set to true, marks this property field to be exported to an XLIFF file during translation. See Content Type Model - Properties for Translation for more details.


If set to false, marks this property field as not being merged automatically from the master content when the translation task is accepted for a derived content. See Content Type Model - Properties for Translation for more details.

Table 4.1.  Common Attributes


With an IntProperty, a field's value must be a whole number.

Example for creating an IntProperty:

 <IntProperty Name="Priority"/>

In a StringProperty field, you can store unformatted text.

Property Description


Maximum number of characters that can be entered


Maximum number of bytes. This attribute is optional. If you do not use this attribute, the value of the attribute Utf8Weight of the <DocTypes> element will be used to calculate the maximum byte length (=Length * Utf8Weight /100). If you set none of the attributes Utf8Length and Utf8Weight, Utf8Weight=300 will be used (see below for details) to define the byte length.


Set to 'true' to make the StringProperty an observed property. This attribute is optional.

Table 4.2.  Attributes of a StringProperty field



When the StringProperty is observed, the length must not exceed 256. Otherwise, the content server cannot start and you will see a log entry like the following in the content server log:

 2018-12-10 15:01:38 [ERROR] hox.corem.server.Server [] - \
Cannot startup due to malformed document type definition: \
The length 257 of the observed StringProperty 'observed' exceeds the allowed maximum length 256 (Init Process) 

Example for creating a StringProperty:

 <StringProperty Name="Title" Length="200" Utf8Length="500"/>

The maximum number of characters to be entered is limited to 200 and the maximum length would be 500 bytes.


Such fields display dates and times. Editors for simple input are available

Example for creating a DateProperty:

<DateProperty Name="Date"/>

Whereas for some properties, such as the author, a simple character string is sufficient, an XMLProperty field specifies an XML document field. XmlProperty fields require a Grammar attribute which refers to the DTD or Schema of the content.

Property Description


Defines the DTD or Schema that should be used for this content. coremedia-richtext-1.0 is the standard grammar for CoreMedia RichText fields. The special predefined grammar coremedia-struct-2008 is used for properties that contain structured objects at the level of the Unified API, but that are represented as markup internally. Structs are typically used for highly dynamic configuration tasks.

Table 4.3.  Attributes of an XmlProperty field

Example for creating an XmlProperty with Structs:

<XmlProperty Name="Config" Grammar="coremedia-struct-2008"/>


You can use a BlobProperty field to store binary data in CoreMedia Content Cloud. The attribute MimeType defines which binary types you can store in the field.

Example for creating a BlobProperty:

 <BlobProperty Name="Graphic" MimeType="image/*"/>

In this property you can store images of all types, such as PNG, JPEG, GIF.


Some content items belong together in terms of content, even if they do not reference each other with internal links in XML texts. For example, images belong to a press report which are not explicitly mentioned in the text as illustrations. The number of images differs from case to case, so that it is not practical to define one field per image in the content type. For such cases there is the LinkListProperty, which holds a list of content items.

Name Description
LinkTypeIf the attribute LinkType is given, all content items of the list must be of the same content type as determined with that attribute or a subtype of that content type.
MinThe minimum amount of references for this link property.
MaxThe maximum amount of references for this link property.

Target items that are linked via weak link property will not be published or withdrawn together with the linking content item automatically. The default setting is "false".

At Unified API level non existing link targets are represented by a destroyed content object. During content bean creation the ContentBeanFactory converts these destroyed contents to null and filters them from created content bean lists.


The introduction of weak links to a document type model comes with a caveat:

  • Weak links can cause dead links in the live environment.

  • Unified API client code has to cope with destroyed contents.

  • Content bean code has to cope with null values and filtered lists of content beans.

Table 4.4. Attributes of LinkListProperty

Example for creating a LinkListProperty:

<LinkListProperty Name="Images" LinkType="Image"/>

Only content items of type Image or subtypes are allowed in this link list.



If you want to create an annotated link list from Blueprint (see Section 7.21, “Annotated LinkLists” in Studio Developer Manual), you have to define an XML Struct property, not a LinkList property.


If you initialize the Content Server, a lot of indices are created in the database. They will speed up the operation of the server, loading of resources, for instance. However, no indices are generated for the user defined content properties by default, because:

  • Indices for properties would only speed up queries.

  • Indices for properties would slow down creation and changing of content.

If you need to have a very fast query via the Site Manager or the Query-API (but not the CoreMedia Search Engine) you might create indices for the DateProperty, IntProperty and StringProperty.

It's possible to create these indices automatically, if you set the attribute Index of the DocType, DateProperty, IntProperty or StringProperty element to "true". If you set Index="true" for the DocType element, indices would be created for all DateProperty, IntProperty and StringProperty fields contained in this content type.

Attributes for Translation

The attributes extensions:translatable and extensions:automerge, which can be attached to all properties, affect the translation behavior. extensions:automerge also affects the synchronization behavior.

Both attributes have no effect when you derive a site. A derived site is a complete copy of the master site. Only links are changed, so that they point to content in the derived site and not to content in the master site.

Translatable Properties

In order to support automatic translation processes, properties of the document model can be marked as translatable. When translating a document automatically, properties that set the attribute extensions:translatable="true" should be included.

<StringProperty Name="keywords" Length="1024"

In general, most string and richtext properties will be marked translatable, excluding those that contain technical strings and identifiers.

See Section “Translatable Predicate” in Blueprint Developer Manual for other ways to mark a property as translatable, for example to mark nested properties of a Struct property as translatable.

Automatically Merged Properties

Usually all property changes from the master content will be merged automatically to the derived content when a translation task is accepted. By default, this applies to both non-translatable and translatable properties, if they weren't changed in the derived content in some incompatible way. However, translatable properties typically differ after first translation, and changes will then not be merged automatically anymore, but updated as part of the XLIFF-based translation. Changes to non-translatable properties are always tried to be merged, to keep binary and structural data in sync between sites, such as images, crops, settings, and the navigation hierarchy. For non-translatable properties, Studio will display a warning if merging is not possible because of some incompatible changes in the derived content.

To disable automatic merging for a property, set the extensions:automerge attribute to false:

<XmlProperty Name="settings" Grammar="coremedia-struct-2008"

For a synchronization workflow, by default all properties are synchronized between a master content and its derived content. You can also disable this behavior by setting extensions:automerge to false or by unchecking the checkbox Keep synchronized with Master of the content in Studio (see Section, “Removing Content Permanently from Synchronization” in Studio User Manual for details).

Note that multi-site properties master, masterVersion, locale, and ignoreUpdates are never merged automatically. These properties are configured in the com.coremedia.cap.multisite.SiteModel.

If needed, the set of automatically merged properties can be further customized with a custom implementation of interface AutoMergePredicateFactory. Such a custom implementation can then be configured in a custom workflow definition for the AutoMergeTranslationAction, see Section, “AutoMergeTranslationAction in Blueprint Developer Manual for details.

Note, that previous releases used a different strategy for auto-merge, and excluded non-translatable properties by default. This has been changed to achieve better results. For backwards compatibility, the old behavior can still be configured, see the description of* configuration properties in Table 4.22, “Workflow Server Properties” in Deployment Manual.

String Properties and UTF-8 Encoded Database

In an UTF-8 encoded database, up to three bytes are required to store a single character. ASCII characters are stored in one byte and non-ASCII Latin-1 characters (such as German umlauts) in two bytes. Asian characters need three bytes for representation.

The attribute Length in the element StringProperty defines the maximum length of allowed characters. The actual byte size of the generated varchar table column in the UTF-8 encoded relational database is a product of the value of Length with an additional factor.

To avoid representation problems and to store even Asian characters the simplest but wasteful way would be to multiply the string Length defined in the StringProperty element with a factor of three to compute the length of the generated varchar table column that holds the string values. In addition to the waste of storage, this could lead to database problems because database boundaries are reached when many string properties with big Length values are specified in one content type or within a content type inheritance hierarchy. To be more flexible, every StringProperty element can have an attribute UTF8Length to specify the maximum number of bytes to hold a string property value. The value must be at least equal and at most three times greater than the value of the Length attribute. If for nearly all string properties in the content type schema the ratio of maximum character length to byte length is the same, one can simply add an attribute Utf8Weight to the DocumentTypeModel element. The value must be between 100 and 300 and, when divided by 100, defines the ratio between character and byte length for all string properties in the type schema where the attribute Utf8Length is not explicitly set. The default value for the Utf8Weight attribute, if omitted, is 300.

For example the value of the attribute Utf8Weight can be set to 130. If a string property with a given Length attribute value of 50 and without Utf8Length attribute is specified, then the maximum byte length is 130/100 * 50 = 65. This may be enough for German text strings, because a string with a character length of 50 could contain 15 two byte encoded characters (such as German umlauts). If the length of a string is less than 49 characters, then even more non-ASCII characters are allowed.



If you are using a Microsoft SQL Server, things are easier. The CoreMedia server uses nvchar for string properties in the SQL Server which can simply be used for Unicode strings. So, you only need to set the UTF8Weight attribute of the DocTypes element to 100. No triple size is needed, no UTF8Length attributes for string properties are required.



If you are using MySQL, things are much easier. The Content Server will always use the defined length for creating columns in MySQL. Do not specify a UTF8Weight or a UTF8Length attribute.

Search Results

Table Of Contents

Your Internet Explorer is no longer supported.

Please use Mozilla Firefox, Google Chrome, or Microsoft Edge.