Module: Content modeling guide

13 of 28 Pages

Store core content into reusable field schemas

While creating a content model or defining the data structure for a content type, you’ll often identify that some fields or sets of fields repeat across different content types. For example, all product-related content types will have the same fields to hold title, product description, product image, and core taxonomy. Some product-specific fields are similar. Other content types used to promote these products might contain the same structure.

To manage these repetitions efficiently, we recommend using reusable field schemas that help you handle such repeated fields across different content types.

The following image shows the Kbank demo site’s content types for storing products: Account, Card, and Loan.

Example of reusable field schema

All three product content types share two groups of schemas – the Core content schema and Financial data schema. While the Financial data schema is relevant only to the products, the Core content schema stores the same content as other content types in the Kbank demo site. For example, we show two more content types that share the same schema: Featured content and Promotion.

Note that each content type has dedicated fields relevant only to that specific content type, such as the Minimal inflow or account type in the ProductAccount type field or the External URL field in the Featured content. See how to approach modeling taxonomies to learn more.

Reusable field schemas from a data perspective

Unlike traditional fields, reusable field schemas give your team flexibility. Both support the same data types, but the reusable field schemas are stored in the ContentItemCommonData table, making them available to every content type. Any changes to a schema also immediately propagate across every content type that references it. However, developers need to ensure that these additional fields display content as intended in the code.

Compose semantic content types with reusable field schemas and dedicated fields

Reusable field schemas rarely constitute complete semantic content types independently, though they can be part of one. Rather than forcing them into semantic content types, use them to define the smallest minor reusable data structure you want to share across multiple content types and have editors input data intended for use across different channels. This will allow your team to maintain consistency in their data while avoiding redundant work.

Functional reusable field schemas

Reusable field schemas can store some core content of semantic content types and define functional data structures that different content types reuse. We’ve already mentioned the financial data schema, which editors work in any Product content type on the Kbank demo site.

Financial data reusable field schema

Similarly, you can define and use an SEO schema across every page content type.

SEO fields in Kbank demo site

To allow editors to add reusable parameters to URLs, developers can define a UTM parameters schema and assign it to different call-to-action buttons, links, or email content types to store data they want to track into analytics tools.

Find out which data types Xperience comes with in Data type management. You will also learn about customizing the out-of-the-box set to support different data types.

Semantic data in reusable field schemas

You’ll identify data that repeats across different content types during a content audit. This might be a heading, some summary text, a reference to an asset, or tags from a specific taxonomy collection.

These schemas represent the Core content that many of your content types contain. Using a reusable field schema avoids the redundancy of defining similar fields across multiple content types. You can define the Core content schema and integrate this schema into other content types. Semantically, they don’t specify a content type that you can find in the schema.org. At the same time, they gather crucial information about the content the company produces, meaning they might be considered semantic.

See the Core content schema shared across the products and articles on the Kbank demo site.

Core content schema in Kbank demo site

When creating field names, we recommend combining the content type’s name with the field name, for example, BenefitDescription, ArticleName, or ProductTitle. Developers can access the field’s values through <contentType>.Fields.<Name> property, for example, page.Fields.NewsTitle. Determining the name of the type within the property name will ease some development situations. For instance, in SQL JOINs, you won’t need aliases to disambiguate between columns from two or more tables, such as News Title and Product Title.