Typing
12 pages filed under Ingestion › Typing. A term is a word of the business with its definition, its aliases and the words it relates to.
| Term | aliases | First line | Links |
|---|---|---|---|
| API | application programming interface, api note | An entity of type api: an interface another system calls, with its protocol, its exposure, its version, its consumers and the objects it gives access to, and the contract that describes it, which the contract import turns into operations. The page of an API lists its operations and carries the contract viewer; an API that nothing consumes yields W-API-NOCONSUMER. | 68 |
| Application | applications, application container | A container of first level, declared under applications: of the configuration with an id, a title and a status (active, legacy or target). Every entity is resolved to one in increasing precedence: the application of its source, the set: { application } of a typing rule, the application of its frontmatter. An entity without one yields W-APP-MISSING, one naming an undeclared identifier W-APP-UNKNOWN; the search results and the breadcrumb of a page show the application an entity is filed under. | 66 |
| Attribute | frontmatter attribute, declared attribute, property | A key of the frontmatter that the profile declares, either for every type (id, title, aliases, status, summary among the common ones) or for one type (url_pattern of a screen, severity of a rule, broader of a term). A typed attribute carries a string, a date, an enum, a list or a reference; a reference produces a link whose relation the profile names. The page shows the attributes in its side panel and highlights the first ones the type's display rules list; a key nothing declares yields W-ATTRIBUTE-UNKNOWN. | 132 |
| Domain | business domain, global domain | A business grouping declared globally, by the name of a folder of the corpus (a folder domain) or by glob patterns evaluated across every source, or proposed by the neighbourhood as an emergent domain for a corpus nobody filed. Repositories are usually split by kind of document; domains cut across them. A note outside every domain lands in the unclassified domain and gets a finding. | 78 |
| Emergent domain | suggested domain, proposed domain | A domain the build proposes from the neighbourhood rather than reads from the configuration, for a corpus nobody filed yet. Every term with a note of its own whose distinct neighbours, over the typed links and the co-occurrences, reach min_neighbours is a pivot; every note no frontmatter, folder or glob files that lies within radius edges of a pivot is a candidate for a domain named after it, attached to the closest pivot, at equal distance to the one of highest degree. A stopword or a term the lock rejects never pivots. The proposal reads as one I-DOMAIN-SUGGESTED finding per reached note and as a section of the build log; nothing is assigned unless the configuration says so, because a growing corpus moves its pivots. A proposal is promoted by declaring the domain, or by naming the note under domains in the lock, and every entity records the origin of its domain: frontmatter, folder, glob, unclassified, lock or inferred. | 51 |
| Folder domain | domain folder, domain by folder | A domain recognised by the name of a folder of the corpus rather than by glob patterns: folder: true claims every note with a directory named after the domain's identifier on its path, in any source, and folder: <name> those under a folder of another name; the file name itself never counts. A subdomain declared this way claims only the notes under its parent's folder, or anywhere on a path the parent's globs match when the parent is declared by globs. Folders and globs combine on one domain with the same precedence, the deepest domain first, and a frontmatter domain still wins over both. | 18 |
| Identifier | entity identifier, id | The name of an entity in the model and the address of its page: the name of its source, then its path relative to the source root without the extension or the type suffix, slugified segment by segment (lowercase, accents removed, every other run of characters replaced by one hyphen), glossary/ingestion/typing/identifier for this repository's ingestion/typing/identifier.md. A frontmatter id takes precedence when it follows the pattern, lowercase with hyphens and at least one slash, and yields E-ID-INVALID otherwise; two files resolving to one identifier yield E-ID-DUP and the first in source and path order is kept. Nothing random, nothing that depends on the order of processing. | 138 |
| Rule | business rule, rule note | An entity of type rule: a constraint with a severity and a condition, and an ## Applies to section naming the screens, processes, objects or APIs it constrains. The rules of this wiki describe the checks of the tool, one note per check, and the rule that binds the linter to the build. | 141 |
| Screen | screen note, page of an application | An entity of type screen: a page of an application, with the roles that use it, the objects it reads and writes, its actions leading to other screens and the rules that constrain it, declared in its frontmatter or under its ## Objects, ## Actions and ## Rules sections. The screens of this wiki are the pages of the generated site, one note per page slot, each with a ## Today section that says what the page renders in this version. | 91 |
| Type | entity type, note type | One of the kinds of entity the profile declares: a screen, a rule, a business object, an API, an operation, a process, a decision, a term, a document among others, each with a label per locale, a glyph, a group, its attributes, the sections whose heading produces a relation, and its display rules. A type is active when the first version renders it and planned otherwise; a project profile adds one without a code change, and a type module carries one from a plugin or a folder of the project. The type of a note is decided by the type cascade, and a type the profile does not know yields W-TYPE-UNKNOWN. | 159 |
| Type cascade | typing cascade, cascade | The order in which the type of a note is decided: the default type of the source, then the type forced by the source, then the source's rules in order (folder, suffix, extension, frontmatter key), then the note's own frontmatter. The most specific wins, and the origin of the decision is kept on the entity and shown in the site. | 55 |
| Type module | type folder, types_dir | The distributable form of a type: a folder named after the type slug that carries everything the type needs, type.yaml with its declaration (group, glyph, attributes, the sections whose heading produces a relation, the display rules), messages/<locale>.json with the labels of the type, its attributes and its sections per interface language, template.md with its note template, and optionally schema.json for the items of its list attributes and components/ for a page, an attribute value or a section rendered specially. The core types are modules and the default profile is assembled from them; a project keeps its own modules in the folder its profile names under types_dir, and a plugin contributes modules through the types contribution point. The modules are merged before the keys of the project profile, plugins first; a module of a core type is refused, that type being extended through the profile, and two modules of one type are a configuration error. | 44 |
12 typing of 12 — pagination by twenty. The Links column counts the related pages, which brings the most central typing of the journey to the top.