Categorization

The Configuration Model in Bloomreach Content determines how repository data outside the model is handled. Repository data is divided into three categories:

Configuration (config)
Configuration is the default category. When you define a new configuration node, all its properties and child nodes are categorized as configuration unless you specify otherwise.
If you force-apply the Configuration Model to the repository, any data in this category that is not present in the model is removed from the repository. Direct child nodes of the root node are an exception; by default, they are categorized as system.
Content (content)
When you force-apply the Configuration Model, data in this category remains in the repository as long as the node it attaches to (for example, base-node in the example below) is not deleted. You can manage this data using content Sources and content actions. You can only assign the content category to nodes, not to properties.
System (system)
When you force-apply the Configuration Model, data in this category remains in the repository as long as the node it attaches to (such as base-node in the example below) is not deleted.

To categorize specific properties or child nodes as content or system, specify the category in your configuration Source file:

 /path/to/base-node:
   system-property:
     .meta:category: system
   /content-base-node:
     .meta:category: content

When you specify .meta:category and its value is not config, you cannot define other sibling properties (including jcr:primaryType).

A category specification does not create the property or node. It only declares the category that should be applied if the property or node exists in the repository.

In the example above:

The property system-property of the base node is treated as system data.
The node content-base-node (including its properties and child nodes) is treated as content.
The base-node itself is treated as configuration.

Consider the following rules:

For nodes, valid values are: config, content, and system.
For properties, valid values are: config and system. You cannot assign content to properties, as it is not possible to load a single property through a content definition.
You cannot specify .meta:category for jcr:primaryType or jcr:mixinTypes.

You can override the category of upstream nodes or properties. When you override a node or property from config to content or system, it is removed from the configuration model and only its category is retained. When you override a node or property from content or system to config, you can specify additional properties, nodes, and values, which are then considered configuration.

To categorize any child node of a base configuration node that is not part of the Configuration Model, use the following meta-definition:

 /path/to/base-node:
   .meta:residual-child-node-category: content
   /configuration-child:
     jcr:primaryType: node:type

In this example, all child nodes of base-node in the repository—except for configuration-child—are categorized as content. This approach allows you to categorize content child nodes without knowing their exact names in advance.

There is no equivalent of residual-child-node-category for properties. You must explicitly categorize each property that is not configuration.