Data Schema¶

Artifact (data schema) — instantiates Interoperability Standardization

Fixes the shared structure, field names, types, and units of exchanged data so information passes between systems without custom per-pair mapping.

A Data Schema is the machine-readable definition of what a piece of exchanged data must look like: which fields exist, their types, their units, their allowed values, whether they are required, and how they nest. Where its sibling specs govern behaviour or meaning-in-prose, the schema governs the shape of the payload at rest and in transit — and it does so in a form a validator can enforce automatically. Its defining move is to make the data structure itself the contract: any producer that emits data matching the schema, and any consumer that reads it, interoperate without either side learning the other's internal model. It standardizes the noun (the record), not the verb (the interaction).

Example¶

A city wants its trip-planning app, its real-time bus displays, and three third-party navigation apps to all consume the same transit data from a dozen independent agencies. Today each agency ships a different spreadsheet layout, so every integration is a bespoke mapping that breaks whenever a column moves. The fix is to adopt a shared data schema — in transit this is GTFS (the General Transit Feed Specification), which fixes files like stops.txt and stop_times.txt down to field names, types, and the fact that stop_lat/stop_lon are decimal degrees and times are HH:MM:SS that may exceed 24:00 for after-midnight service.

Once every agency publishes to that schema, a new navigation app integrates once against GTFS rather than a dozen times against a dozen layouts. A validator rejects a feed that omits a required field or puts a string where a coordinate belongs, so most incompatibilities surface before anyone relies on the data — the outcome is that a rider in a new city gets working directions on day one.

How it works¶

The schema is authored as an explicit structural definition — field list, data types, cardinality (required/optional/repeated), value constraints, units, and how records reference each other by identifier. Its leverage comes from being declarative and checkable: because the structure is written down in a formal grammar (a JSON Schema, an XSD, a protobuf definition, a fixed CSV layout), conformance of a single data instance can be decided mechanically, not argued. The schema deliberately says nothing about how each system stores the data internally or what messages they exchange — it constrains only the crossing payload.

Tuning parameters¶

Strictness — whether unknown fields are rejected or ignored. Rejecting catches errors early; ignoring lets producers add fields without breaking old consumers, at the cost of silent drift.
Required vs. optional split — how much every payload must carry. A large required core guarantees rich interoperation but raises the bar to publish; a lean core widens participation but pushes work onto consumers.
Type tightness — free-text vs. enumerated/coded values. Coded values (units, currency codes, status enums) prevent silent misreads; free text is easier to produce but re-opens the semantic gap.
Identifier discipline — whether keys are locally chosen or drawn from a shared namespace, governing how cleanly records from different sources join.
Extensibility slots — whether the schema reserves a namespaced area for producer-specific fields (see Extension Point Policy, held by Protocol Specification).

When it helps, and when it misleads¶

A schema is the cheapest, most durable interoperability win when the interaction is essentially data hand-off — one system produces records another consumes. It collapses N×N mappings into one target, and because it is machine-validatable, it turns "we think our data matches" into a pass/fail. It achieves syntactic interoperability: the receiver can parse every field.^[1]

Its blind spot is precisely there. A schema guarantees the receiver can read status = 2; it cannot guarantee both sides mean the same thing by 2 — that is semantic, and a tidy validator green-light can lull teams into shipping data that parses cleanly and is interpreted wrongly. It also says nothing about the sequence or timing of exchange. The classic misuse is over-fitting the schema to today's one producer, freezing everyone else out; the discipline is to design the required core around the cross-system function, push everything else to optional or extension fields, and pair the schema with a shared vocabulary for the coded values it references.

How it implements the components¶

shared_standard_specification — the schema is the shared rule set for the data facet: the common structure independent systems implement against.
semantic_alignment_rule — at the field level it pins units, enumerations, and identifier formats so stop_lat is always decimal degrees, not a silent mix.

It does not state the boundary's operation- and error-contract — that is Common API and Protocol Specification — nor define the domain-wide meaning of terms and categories, which is Semantic Glossary; the schema fixes machine types, the glossary fixes human meanings.

Instantiates: Interoperability Standardization — the schema is the standardized data surface participants exchange across.
Sibling mechanisms: Protocol Specification · Semantic Glossary · Technical Standard Specification · Common API · Conformance Test Suite · Reference Implementation · Certification Program · Interoperability Trial · Standards Body · Version Negotiation Scheme · Interagency Interoperability Agreement

References¶

[1] Syntactic interoperability — systems can exchange and parse data — is the layer a schema secures; it is routinely distinguished from semantic interoperability, where the parsed data is also interpreted identically. Conflating the two is the standard way a schema-only integration goes wrong. ↩