The ORE XML infrastructure
Table of Contents
1. What this cluster answers
A person changing how an ORE document is stored has four questions. Which component may read the XML? Where does a value change form? Which row is a given element? What makes a value legal? Six pages answer them, in an order that follows the dependencies between the answers rather than the file layout.
2. The order, and why it is the order
The sections are in dependency order, not reading order. Each one says what it makes possible for the page after it.
2.1. The document's shape has one owner
One component reads every ORE document, and none of them stores XML
ores.ore holds the code for each of the five documents a run names, and no
other component parses ORE XML. A store receives typed rows. Read this first
because every rule in this cluster acts on rows: a reader who does not know where
the XML stops cannot tell which page owns a change.
2.2. A value changes form at two boundaries
A stored value reaches the row in the form the value set names
A rendering becomes the stored form at the codec, for the document families the codec reads, and at the database guard, for every other writer. It follows from the boundary above: the codec may state the store's form because that form is a file, not a demand on the store. It comes next because it settles what the value means for everything below it.
2.3. The way out is not the way in
The export writes the stored form, so a round trip is not byte-identical
The export builds the documents from rows by reversing each projection. Because of the conversion, the rendering the imported file used does not survive the store, and this page says why that is correct and what the two round-trip tests assert instead.
2.4. Which element a row is
One map answers which ORE element a row is
Identity, now that the value is settled: eight tables touch the document, and the leaf question has one answer that both guards join. Knowing which of the eight a write passes through is what makes the next page's rule checkable.
2.5. What makes the value legal
A value set is the only place an ORE parameter's rule is written
A parameter or a leaf element resolves to one value set, and the set states the kind, the bounds, the pattern, the catalogue and the values. Nothing else in the tree repeats it. The identity page is the lookup; this page is what the lookup lands on.
2.6. Who refuses an illegal value
The database refuses a value that no value set states
Enforcement comes last because it depends on the set being reachable from every writer. Four trigger functions and one verdict function refuse the value, and why the verdict runs as a definer belongs to this page.
The identity page and the value set page can be swapped by a reader who wants only the data model. The first two cannot be: the conversion is a consequence of the boundary above it.
3. What this cluster does not cover
The screens are a neighbouring cluster, not this one. How a value is drawn, the words a control uses, and what a screen offers as a choice belong to the ORE element and leaf screen standard, which reads the value sets this cluster describes. The two meet at one rule: a screen offers what the set states and refuses nothing of its own, so the set has to be complete before the screen can be.
Three more neighbours, and why each boundary falls where it does:
- Pricing Configuration covers the configurations as a product feature: what a party configures, and when a run uses it. This cluster stops at the row.
- ORE Products by Asset Class covers what the products mean. This cluster only cares that a product type is a key in the document.
- Market Data Architecture covers where the numbers come from. A market data file reaches ORE by another path and is not one of the five documents here.
4. See also
- Zettelkasten — the method this hub follows: it gists and links, and holds no claim its cluster does not. Completes the cluster by saying how the pages are written.
- Knowledge — the index this hub is filed under, in the Architecture table.
- ORE element and leaf screen standard — the improbable neighbour: a UI page that constrains this data model. Answers the question a reader of the value set page asks, which is why the set must be complete rather than merely used: a screen may not carry a rule of its own.
- PostgreSQL Architecture — the row-level security and bitemporal conventions the value set tables and the guards are built on. Exemplifies the platform rules the cluster relies on.