Let's Evaluate the Current Level of Functionality

We’ve described a fair amount of functionality. Let’s take a quick timeout here to wrap up what we’ve detailed into a hypothetical CMS and then consider what that gets us.

Here’s what we’ve talked about so far, and what a theoretical system encompassing all of the discussed functionality would look like:

It would have a built-in model of some kind, perhaps consisting of a Title, Body, URL Segment, Publication Date, and Categories assignment for every content object. We’ll assume this is a web-focused system, so the Body attribute would consist of rich text, and there is no distinction between content and metadata.
This built-in model could be extended into multiple, named content types with the addition of new attribute types. Each content type could be instantiated into multiple content objects of that named type.
We have a variety of attribute types available to be added to the built-in model to create a new content type – simple text, rich text, checkboxes, selection lists, date pickers, etc. All these types provide a custom interface element for editors to use when creating content. The interface elements all coerce the creation of an attribute value of a specific format, and they prevent editors from creating invalid values.
The attribute values can be logically validated by a variety of rules. Values can be required, default values can be specified, and they can be tested against ranges (for numbers, dates, or text length) or regular expression patterns. Each attribute can be assigned multiple rules, and this validation can be deferred until an editor attempts to publish the content. Validation error messages can be custom to each attribute.
Attributes can be labeled with a title to be displayed to editors. Each attribute can have helpful explanatory text, accessible from the editorial interface. Attributes can be placed in a specific order on the editorial interface, and can be arranged into logical groupings.
Attributes can be references to other content objects. These references can be coerced by type, and a dependency management system will notify us of potentially broken references before we delete objects.
When working with retrieved content objects, they are converted into native data structures from the underlying programming language, and we can add additional logic to those structures to support pseudo-attributes as necessary.

This is a system that incorporates every desirable feature we’ve discussed so far. What we’ve described above is a fairly competent system, and one that reflects quite a bit of what’s available in the market today. Fifteen years ago, in fact, this might have been considered advanced.

If our system only included the functionality we’ve described so far and nothing else, it would be simplistic but serviceable, and a competent integration team could use it as a fundamentally sound tool.

It’s also worth noting this: at this point, we’ve essentially just duplicated the functionality of a relational database.

Content types are tables
Attributes are data-typed columns
Content objects are table rows
Validation rules are field constraints
Referential attributes are foreign keys

This isn’t to say the work we’ve done so far has just gotten us back to the start, because remember that a CMS provides considerable functionality around content modeling. In addition to supporting a set of database-like functionality, a CMS gives you things like automatic editorial interfaces, workflow, permissions, templating, delivery, etc. It is fair to say that a CMS is a superset of database functionality – a “super database,” if you will.

We’ll discuss content services when we discuss the difference between content and everything else.

We still have a long way to ago, and a lot of advanced functionality to cover, but it’s a fair point to say that the above functionality is the “table stakes” of competent content management at the current state of the industry.

If your system cannot support almost all of the above base functionality, then it’s either behind the curve, or it’s not designed to be a general-purpose CMS.