The ARX specification

1. 01 Entities and values
2. 02 The schema catalogThe **schema catalog** is what the developer declares about the tables, once, at startup, and gives to the service. A service with a catalog never reads table definitions from the database during an operation; only an explicit startup step does (the preload, below). A service created without a catalog, on a provider that declares the SchemaResolution capability (08), reads each table's id column, keys and column types before the call that needs them; that is the one exception, and the developer chooses it by leaving the catalog out.
3. 03 OperationsEvery provider offers the same operations, with the same names, parameter order and result shapes. All are asynchronous and take a cancellation token. A provider that can't do an operation, or part of one, must refuse it with ARX8001 NotSupported naming what it can't do, never ignore part of it (chapter 08).
4. 04 QueriesA **query** (`ArxQueryExpression`) names an entity and has criteria, columns, an order, links, aggregates and paging.
5. 05 Transactions and batch scopes
6. 06 ErrorsEvery error an implementation raises is an **ARX exception** with a stable **code**: the same number and name in every provider and every language. The message starts with both (`ARX3001 UniqueViolation: …`). The **category** is the code's thousands digit. A provider keeps the database's own error on the exception (its native code, and the driver's error as the inner exception) but never puts values into its own messages.
7. 07 Names and injection
8. 08 CapabilitiesProviders differ. Each declares what it supports as **capability flags**, so code can choose a path before it calls, and the rule is the same everywhere: **a declared capability is done correctly; an undeclared one is refused with ARX8001 NotSupported, naming what can't be done.** No provider silently ignores part of a call or answers it differently.
9. 09 The paging cookieProviders with TokenPaging return, with each page that has a next one, an opaque **cookie** the caller passes back for the next page. Its format is shared, so a cookie is checked the same way everywhere: it belongs to one provider and one query, and may be signed.
10. 10 ConformanceThe specification is checked in two ways. The test vectors (chapters 04, 06, 07 and 09) need no database: every implementation runs them. The conformance suite runs the rest against real databases: one set of tests that every .NET provider passes, on every change, against its own database in CI. Where a provider behaves differently from another, the suite either finds a declared capability that explains it or fails.

Each vector file is JSON an implementation reads and checks itself against; they need no database. The conformance chapter covers what is checked against real databases.

• error-codes.jsonEvery error code: its number, name, category and whether it is transient.
• injection-check.jsonNames that are refused as an injection attempt, and names that are not.
• echo.jsonHow a refused name is echoed safely in a message.
• paging-cookie.jsonPaging cookies byte for byte, and the ones that must be refused.
• conditions.jsonThe condition truth table: an operator, its values and a stored value, matched or not.