Schema: The Art of Describing Abstract Data

Summary

Data is easy to store, transmit and process. Understanding what that data means is much harder.

A schema is more than a validation mechanism. It is a description of meaning. It provides a shared vocabulary that allows humans and systems to interpret abstract data consistently.

Whether expressed through XML Schema, JSON Schema, database definitions, API specifications or even paper forms, a schema exists to answer a simple question:

What does this data actually represent?

---

A Small Problem

Consider the following JSON document:

{
    "A": 52,
    "B": 1,
    "C": 3
}

It is valid JSON.

A parser can read it.

A computer can store it.

But what does it mean?

Nothing in the document tells us.

The computer knows:

A is a number.
B is a number.
C is a number.

But it does not know what those numbers represent.

Neither do we.

Without context, the data is almost meaningless.

Schema Version 1 - Playing Cards

A schema tells us:

A = Card Value
B = Suit
C = Number of Cards

and:

Suit:
1 = Hearts
2 = Diamonds
3 = Clubs
4 = Spades

Suddenly:

<syntaxhighlight lang="json"> {

   "A": 52,
   "B": 1,
   "C": 3

} </syntaxhighlight>

becomes:

Three cards from the Hearts suit.
Highest card value 52.

Not especially exciting, but meaningful.

The values have not changed.

Only our understanding has changed.

Schema Version 2 - Aircraft

Now imagine a different schema:

A = Altitude (Thousands of Feet)
B = Aircraft Status
C = Engine Count

and:

Aircraft Status:
1 = In Flight
2 = Grounded
3 = Taxiing

The exact same JSON now becomes:

Aircraft flying at 52,000 feet
with three engines.

The data is identical.

The meaning is completely different.

Schema Version 3 - A Hospital

Now consider a hospital system.

The schema defines:

A = Patient Age
B = Priority
C = Ward

and:

Priority:
1 = Critical
2 = Urgent
3 = Routine

The same data becomes:

52-year-old patient.
Critical priority.
Ward 3.

Once again, nothing in the JSON changed.

Only the schema changed.

Beyond Simple Definitions

Modern systems rarely stop at simple field definitions.

A schema may define:

Field Names
Data Types
Relationships
Constraints
Documentation
Validation Rules
Units
Permitted Values

So the same data might expand into:

Patient Record
├── Age: 52 Years
├── Priority: Critical
└── Ward: Cardiology

or:

Aircraft Telemetry
├── Altitude: 52,000 Feet
├── Status: In Flight
└── Engines: 3

or:

Inventory Item
├── Quantity: 52
├── Warehouse: London
└── Shelf: 3

The schema transforms simple values into structured information.

The Schema Does Not Hold Data

A common misconception is that schemas describe data.

In reality, the data already exists.

The schema describes how the data should be interpreted.

A schema transforms values into knowledge.

Schema as a Form Template

Another useful way to think about a schema is as a form.

Consider the following paper form:

First Name:    ____________

Last Name:     ____________

Date of Birth: ____________

Email Address: ____________

Although the form contains no data, it already tells us a great deal.

It tells us:

• What information is expected
• Where that information belongs
• How the information is organised
• What each value represents

The form is acting as a schema.

Now imagine somebody completes the form:

First Name:    Dex

Last Name:     White

Date of Birth: ____________

Email Address: dex@example.com

The values have been added, but the structure has not changed.

The form already defined the meaning of each field before any data was entered.

If we look closely, every completed field contains two parts:

First Name: Dex
^^^^^^^^^^  ^^^
Schema      Data

The label on the left describes the value on the right.

This is exactly what a schema does.

Without the label, the value is merely text.

With the label, the value becomes information.

The same principle applies to databases, APIs, XML documents, JSON documents and paper forms.

The schema defines what information can exist.

The data provides the values.

Together they create meaning.

More Than Validation

Many technologies use schemas to validate documents.

A good schema also explains:

What fields exist
What those fields represent
How they relate
What values are permitted
What assumptions are being made

In other words, a schema documents the language spoken by the data.

The Map Legend

Perhaps the simplest way to think about a schema is as a map legend.

Without the legend:

▲ ● ■ ★

the symbols are meaningless.

With the legend:

▲ Mountain
● Town
■ Railway Station
★ Capital City

an entire landscape appears.

The symbols have not changed.

Your understanding has.

Schemas perform exactly the same role for data.

The Real Lesson

Whether using XML, JSON, YAML, CSV, relational databases or paper forms, the underlying problem is unchanged.

The data itself rarely explains its own meaning.

Meaning emerges from shared understanding.

A schema records that understanding.

It defines the vocabulary, the relationships and the assumptions that allow abstract values to become useful information.

A schema is not merely a validation tool.

It is a way of describing the world represented by the data.

Perhaps the most important lesson XML ever taught us is this:

Data tells us the value. A schema tells us what the value means.