Every entity in a document MAY carry an ext object. It holds what a producer knows that the specification does not cover, such as a queue priority, a trace id or a framework’s own state name, without inventing new fields.

​
Namespaces

  • An ext key SHOULD begin with a reverse-domain namespace the producer controls, such as com.example. for a tool at example.com, so that two producers never collide.
  • A consumer MUST ignore namespaces it does not understand, at every level, and MUST NOT fail on them.
  • A producer SHOULD put its own data in ext, not in new fields next to the specification’s.
  • Under the full privacy profile, text MAY appear in ext; under metadata_only, ext is bound by the same rule as every other field.

​
Extensions that change meaning

An extension is ignorable by definition, with one exception so far: control.ext["dev.loopmath.gate_rules"] maps a gate to a rule other than its role’s default. A different gate rule changes what ran, so this key is part of the configuration id. A reader that ignores it can still read the document, but cannot recompute the id. loopmath writes a few other keys that a reader may find useful:

​
From extension to field

When several producers write the same kind of data in their own namespaces, it is a candidate for the core format. A proposal can promote it to a field in a minor version; producers then write the field and MAY keep writing the extension for older readers.

Privacy