Skip to content

The Table Lifecycle⚓︎

By this point, the full mental model is visible: a feature table starts as authored text and ends as validated Python output.

Here is a compact content table:

Authored compact table
Given the content exists
  | IDs  | 1-3        |
  | Type | 3 Articles |

The test code would rather work with a logical table:

Logical table after expansion
[
    ["IDs", "1", "2", "3"],
    ["Type", "Article", "Article", "Article"],
]

The lifecycle is the path between those two views and the final output objects.

Conceptual lifecycle
authored table text
  -> source-aware cells
  -> optional table transform
  -> shape and label checks
  -> field parsing
  -> records
  -> references and validation
  -> parse() returns records
  -> parse_as() builds output objects

Each stage has a job⚓︎

Source-aware cells remember where the value came from. A table transform can turn compact authoring syntax into a more regular logical table. Shape checks make sure labels and rows are usable. Field parsers convert cell text into Python values. Validation checks the records and the table as a whole. Output construction gives the test the object style it wants.

parse() and non-raising validate() stop after validation and return schema records. parse_as() continues into output construction. Each phase produces the same Diagnostic Model v1 values, and an error stops later work that depends on complete records. Warning-only validation keeps the records.

One schema can own the lifecycle
from talika import ColumnGroupExpander, ColumnTable, NumericRange, PrefixRepeat
from talika import field, id_field


class ContentTable(ColumnTable):
    table_transformer = ColumnGroupExpander(
        key_row="IDs",
        range_rule=NumericRange("-"),
        repeat_rule=PrefixRepeat(" "),
    )

    id = id_field("IDs")
    content_type = field("Type", required=True)

You usually customize one stage

Most projects do not need to replace the whole lifecycle. They define the table shape, choose parsers, maybe add validation, and let the rest of the pipeline stay ordinary.

Why the lifecycle matters⚓︎

Calling this "just parsing" misses the point. The hard part is not only turning one string into one value. The hard part is preserving author intent while the table moves through shape checks, transformations, validation, references, and output construction.

The advanced guides show how to preserve authored cells during transformation and how validation fits before output conversion.

The source cell remains important

Even after a compact table expands into several logical records, the original authored cell should still be available for diagnostics. That is what makes advanced table language safe for feature authors.