Eval Criteria # 2

Can the built-in model be extended with custom content types?

Given every system has a built-in content model, can you extend this to create your own content types? From a modern perspective, you might think, “well, of course…”, but this isn’t always automatic, especially with older systems and systems designed for specific use cases.

Some systems are designed to be extended, and, in fact, would be fairly useless if not extended. These systems have a stripped-down built-in model because they intend it simply as a starting point. These systems have many built-in attribute types, and an expected part of development is for you to define the content model and new types to fit your situation.

Other systems allow extensions grudgingly, perhaps offering the ability to add some “custom fields” that only store text and cannot be validated. These systems might have a rich built-in model which is often meant to serve the needs of a particular use case for which the software was designed. These systems likely maintain some glimmer of hope that their built-in model won’t need to be extended at all.

Other systems simply don’t allow any model extension. They are what they are. These systems are usually subscription-based or meant solely to service some particular use case (which is the subject of the next chapter).

CityDesk was an early, desktop-based CMS. You can see here on the “extras” tab that it had some usage-appropriate attributes, and two special attributes – Extra 1 and Extra 2 – which we designed to hold…whatever. And this was it. If you needed an Extra 3 you were out of luck, or you had to just re-use one of the existing fields.

Content vs. Metadata

In some systems, there is a distinction between content and metadata. The former is what you’re actually managing, and the latter is…other stuff. It’s like the opening act and the headliner at a music concert. You came for the headliner; the opening act is just extra.

This model is more easily illustrated in the document management space – these are systems that manage files (Word, PDF, etc.) and allow you to store other data about those files.

When you have a file you’re managing, the file is the thing, and the metadata is…extra. You’re clearly managing the file as the content. The metadata is just extra information that enhances the data in the document.

Some early CMSs follow this same model, as they were just thin wrappers around rich text editors that generated chunks of HTML, or files that contained HTML. The idea was editors would edit the HTML content, and they would enhance it with metadata to provide organization and structure around it.

In these systems, the metadata was separate from the HTML content. So, the content was the content, and the “metadata” was…extra.

Serena Collage was a CMS-ish wrapper around a traditional source-code management system – imagine if someone turned Git into a CMS.

As such, an actual, versioned HTML file was the thing you were managing, and your only ability to add structure was to add “metadata” around this file. Collage had a dialog box where you could specify additional information to connected to the file and used in other contexts, like lists of content. The file was the thing, and the metadata was…extra.

(Note: I tried very hard to find a screencap of this, but Collage is a system in rare usage these days. Multiple requests and retweets on Twitter could not produce a working instance of it anywhere.)

Other file-based systems have used the idea of a “sidecar file” which is a file sitting alongside the “content file” which provides metadata that can’t be stored with the file. If the actual content is in “article.html”, a file next to it named “article.info” might store the metadata. The CMS knows to look for this file-naming structure for the metadata associated with content.

Ektron (acquired by Episerver in 2015) separated the concept of “content” and “metadata.” For a long time, “content” was just rich text – the “Content” tab in the image is just a “what you see is what you get” (WYSIWYG) editor. When Ektron wanted to add the idea of extendable, structured content, they put it in a separate tab. So your content was unstructured rich text, and your metadata was extendable, structured data.

The content/metadata dichotomy is less relevant today. The days of managing content as big chunks of HTML are (thankfully) mostly behind us, and most content has a higher degree of structure.

And this brings us to the awkward question of whether metadata in the classic sense even exists anymore.

Here’s the definition of the prefix “meta”:

A prefix added to the name of a subject and designating another subject that analyzes the original one but at a more abstract, higher level

So, the word “metadata” literally means “data about data.” The idea was the metadata was used as a tool to organize, clarify, or filter the “main” data. This means that to say something is metadata is to tacitly admit it’s modifying some other data, which exists somewhere else.

Metadata only has meaning as a concept if it’s separate from some other data. Refer back to the document management scenario and it makes more sense because the document is “the thing” and the metadata is “the other thing.”

But what if there’s no document or big chunk of HTML? What if there’s no thing?

Put another way, what if everything is metadata? If everything is metadata, then nothing is. There is no “other.”

The truth is that with most modern CMSs, the idea of “metadata” doesn’t exist. All data is structured, and it’s lumped into the same interface.

Let’s come back to the original question: can the built-in content model be extended at all?

The lack of this ability is rare, but if you cannot extend the built-in model, then you need to be absolutely convinced it will do everything you need, both now and in the future. These situations are not common, and usually only exist in unapologetically use case-specific systems like those created for a particular industry vertical.

Assuming we can extend the built-in model, let’s find out what attribute building blocks we have available.

Evaluation Questions

Is it an expectation that the built-in model will be customized and extended by those implementing the system?

Can new content types be configured?

Is there an explicit difference between content and metadata?