Lexicons everywhere

There is one schema language in the system. Records are Lexicons. Extracts are Lexicon defs. Views are Lexicon defs. The manifest and the binding document are Lexicons too. That is what lets one validator, one type generator, and one documentation generator cover everything.

What a Lexicon gives you

A Lexicon document has an id (an NSID such as app.fruitful.feed.hackerNews.submission) and named defs. A record def is a persisted thing with an identity; an object def is a shape. Properties carry real types and formats (uri, datetime, nsid), and ref properties point at other defs, in the same document or another.

From one document the tooling derives:

• runtime validation, applied to every extract item, record, and View before persistence;
• TypeScript builders and parsers for authoring (Post.$build, Post.$parse), so an invalid record fails to compile;
• a JSON Schema for editors, published for the manifest and binding document;
• the Reference, rendered from the descriptions in the Lexicon.

Identity and links are read, not restated

A record's identity is always its /uri. A link to another record is a ref to that record's #recordRef. The manifest never repeats either: the runtime reads them from the pinned Lexicon. This is why transform.records is a list of pins and nothing more.

The manifest is a Lexicon so it can be strict

Lexicon objects are open by default. The manifest parser pairs the generated validator with a strict-keys walk, so an unknown lifecycle point or a misspelled field is rejected rather than ignored. What the Lexicon cannot express, that a route's login exists, that a hook is exported, that a pin is declared, is declared as data in the relationship rules and checked by one walker.

Shared versus package Lexicons

Fruitful ships shared Lexicons for things every package needs: accounts, web documents, media, the manifest and binding schemas. A package ships its own for its records and View, and pins the shared ones. A definition that includes a copy of a shared Lexicon is refused. See Shared Lexicons.

Versions

Lexicon packages are versioned and pinned by range, like every package. A change that keeps existing records valid is a minor bump; a change to identity, required properties, or relationships is a major bump and a new package version for every consumer.