Skip to content

4. Identifiers

Contents of DID 0.2

Every element, relation, port and view carries an id that is unique within the definition and matches the specification's persistence.ids.pattern (default ^[A-Za-z0-9_.:#-]{1,128}$). New ids are generated as the specification's persistence.ids declares (DISL 11.5). Unless the specification sets stable: false, an id MUST NOT change once assigned. References between records (parent, relation source and target, reference-typed attributes, the keys of nodes and edges in a view, a suppression's element) are ids. Nodes, relations and views share one id space; ports are in the id space of their element when port ids are written "<elementId>#<portId>".

Writers. A writer MUST NOT write a record with a missing or empty id, an id that does not match the pattern, or an id that another record of the definition already has. id stays required in the schema, because the schema describes what writers produce. A save writes back unchanged the records the user did not edit, so a duplicate made by hand stays until the user resolves it; a writer MUST NOT change an id to resolve a duplicate except through a user action, such as the quick fix of std.duplicateId.

Readers. A reader MUST load a definition in which ids are missing or duplicated, and MUST report each case as a finding, std.missingId or std.duplicateId (DISL 8.7), instead of refusing the definition:

  • Of the records that share an id, the first in record order (elements, then relations, then views, each in array order) keeps it: every lookup and reference resolves to it. The second and later are loaded and treated as ephemeral (DISL 11.5) until the duplication is resolved.
  • A record without a usable id (absent, empty, or not matching the pattern) is handled as the specification's persistence.ids.missing declares. With "assign", it receives a new id from the applicable strategy; the new id MUST NOT be written when the definition is opened or validated, and MUST be written by the next save that writes the definition. With "ephemeral", it is loaded and treated as ephemeral.

Comparison. Ids, including references and the keys of nodes and edges, are compared as the specification's persistence.ids.compare declares: exactly by default, or with "ignore-case" under Unicode default case folding, in which case the spelling of the first occurrence in record order is kept.

Derived ids. An id whose strategy is derived (DISL 11.5) is recomputed from the model on load. When the recomputed id differs from the stored one, the record takes the recomputed id and the references to it (parents, relation ends, reference attributes, view keys and suppressions) follow; the new id is written by the next save.

Referenced from