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.

Caution

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.

Caution

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:

When defining XML elements and attributes in the following sections, the default namespace is assumed to be http://www.coremedia.com/2008/documenttypes and the namespace prefix extensions is assumed to be bound to the namespace URL http://www.coremedia.com/2013/documenttypes-extensions.

Common Attributes

You can add the following attributes to each property:

IntProperty

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

Example for creating an IntProperty:

 <IntProperty Name="Priority"/>

StringProperty

In a StringProperty field, you can store unformatted text.

Caution

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.

DateProperty

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

Example for creating a DateProperty:

<DateProperty Name="Date"/>

XmlProperty

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

Example for creating an XmlProperty with Structs:

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

BlobProperty

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.

LinkListProperty

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.

Example for creating a LinkListProperty:

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

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

Note

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

Indexing

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:

If you need to have a very fast query via 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 content model can be marked as translatable. When translating a content item automatically, properties that set the attribute extensions:translatable="true" should be included.

<StringProperty Name="keywords" Length="1024"
  extensions:translatable="true"/>

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"
extensions:automerge="false"/>

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 4.7.4.3, “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 workflow.localization.auto-merge.* configuration properties in Table 3.33, “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.

Note

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.

Note

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.