CoreMedia Content Server Manual, Version 7.5.45-10
Chapter 4. Developing a Content Type Model | 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.

	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.

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.

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 document 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 Digital Experience Platform 8. 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.

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 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.

Translatable Properties

In order to support automatic translation processes, properties of the document model can be marked as translatable. When translating a document automatically, only 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.

Automatically Merged Properties

Usually all non-translatable properties in the master content will be applied automatically to the derived content when a translation task is accepted. This helps to keep binary and structural data in sync between sites, such as images, crops, settings, and the navigation hierarchy, and complements the XLIFF-based update of translatable properties. To enable the automatic merge for a translatable property or disable the automatic merge for a non-translatable property the extensions:automerge attribute has to be attached.

      <XmlProperty Name="settings" Grammar="coremedia-struct-2008" extensions:translatable="true" extensions:automerge="true"/>

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.