Skip to content

Conformance checklist

This page collects checks for syntax processing, common string decoding and consumer behaviour. The configuration format specification remains the source of the rules; this checklist does not add new behaviour. Consumer-layer checks apply to implementations that provide that layer; they do not require a syntax-only parser or the shared syntax corpus to provide retrieval APIs.

Implementation conformance is checked against the rules defined in the configuration format specification and the following aspects.

AspectChecks
File declarationsRequired leading declaration region and blank separator; exact @dotReg 0.1, ASCII SP/HT separation and trailing whitespace, initial BOM, rejection of missing/malformed/duplicate/unknown declarations and unsupported versions (including version 1), no comments in the region, valid empty body, no declaration entries, physical line numbers including the region, ordinary @Name body keys and declaration-looking block data
Filename extensionsNo extension requirement for syntax; .dotreg is the default convention, .conf is also suitable, and content validity does not depend on the extension
Key pathsProhibited characters, including backslashes, and the non-empty requirement for unquoted elements; Japanese, underscores, hyphens, keys and headings beginning with digits or consisting only of digits; rejection of consecutive unquoted dots, empty left-hand sides and omitted final elements; case sensitivity; preservation of elements with leading zeroes
Quoted key elementsAllowing any valid UTF-8 string in principle, without a blanket rejection of whitespace, tabs, syntax symbols or control characters; empty names written as ""; the requirement for at least one element; quotes in first, intermediate and last positions; application to fully qualified keys, relative keys and headings; distinction between the parent itself and a child with an empty name; preservation of element boundaries; rejection of quoted text spanning physical line breaks
Escapes in key elementsAcceptance of the basic and Unicode escapes in section 3.4 within quotes; identity of "A\.B" and "A.B"; rejection of A\.B with a backslash outside quotes; recognition of separators, heading terminators, leading relative dots and assignments to headings themselves outside quotes; no reinterpretation of decoded characters as syntax symbols
Invalid escapesRejection of unknown or incomplete escapes within quotes; preservation of unquoted \q and trailing backslashes; no line continuation for trailing backslashes, whether quoted or unquoted
Unicode escapesOne to six ASCII hexadecimal digits within braces; acceptance of both cases and leading zeroes; acceptance of the four-digit form and correct surrogate pairs; identity of direct and escaped forms; rejection of values outside the scalar range, isolated surrogates, reversed or mixed-form pairs, and invalid digits or digit counts; no substitution with the replacement character; acceptance of noncharacter and unassigned scalar values
Coexistence of keysA, A.B and A.B.C can each have a value
Unicode identityNo normalisation; exact comparison of decoded elements; precomposed characters and combining sequences coexist as distinct keys; the same rule applies to retrieval and schema matching; type expressions and values are not implicitly normalised either
Equivalent notationFully qualified keys, headings, relative notation and assignments to headings themselves resolve to the same fully qualified keys and right-hand sides
Indentation and headingsExactly two additional ASCII spaces per written heading level, including assignment to a heading itself; even structural indentation, logical depth d/2 and parent indentation d-2; rejection of odd indentation, tabs, unindented relative lines and missing parents; closing headings when indentation decreases; closing headings with absolute lines; preserving state across blank lines and comments, whose indentation is exempt
Type annotation position and alignmentOptional left-hand annotations only on value lines; rejection of annotations on headings and inheritance to children; zero or more ASCII spaces between the key and type expression, between the closing parenthesis and colon, and after the colon, with equivalent meaning; rejection of internal whitespace; extraction with balanced parentheses; no blanket prohibition on symbols for compound types; distinction from parentheses on the right-hand side
Type-name conventionWrite simple type names in lowercase English by convention; retain the general syntax layer’s support for opaque expressions beyond ASCII letters
Preserving right-hand sidesRemoving outer ASCII spaces and tabs only from single-line values and headers; preserving internal whitespace, Unicode whitespace, quotes, leading zeroes, colons and #; retaining each block body after removing only its structural markers and margin
Common string decoding of valuesAfter outer ASCII SP/HT removal, selecting quoted syntax only from an initial double quote; otherwise preserving the whole single-line value literally, including later unbalanced quotes, triple quotes and backslashes; removing ordinary surrounding quotes and decoding escapes only for quoted forms; literal pipe bodies; no reinterpretation or second trimming; distinction between explicit empty and unset; rejection of invalid starting quotes, trailing text after their closing quote and invalid quoted escapes without fallback
Empty right-hand sidesTreating empty right-hand sides, and those containing only outer ASCII spaces and tabs, as unset unless the immediately following line starts a pipe block; distinguishing unset from explicit empty quoted or block values, the string null, headings, omitted keys and non-empty right-hand sides ending in a colon; applying the same rules to type annotations and assignments to headings themselves
Triple-quoted valuesExact opening marker without inline content, recognised only in the value header; no transition into a block at later quotes or lines; closing-marker meaning only within an open block; own-line closing marker; closing-margin removal from every non-empty source line with empty-line exemption; raw closing margin independent of the two-space hierarchy rule, including odd and zero margins; insufficient-margin and missing-close rejection; ordinary quoted escapes; literal internal quotes and triple quotes outside exact closing lines; no reinterpretation or normalisation
Pipe blocksImmediate-next-line detection after an empty header; strictly deeper raw ASCII-space indentation, permitting odd counts and a one-space increase independently of the two-space hierarchy rule; consecutive markers only; literal body after stripping leading spaces and the first pipe; no skipped blank lines or comments; normal processing of the first non-body line; A:| as a single-line value and non-body |: lines subject to ordinary key and indentation rules
Multiline state and line endingsExplicit empty bodies are set; original LF or CRLF between body lines; no opening or closing boundary newline and no inferred terminal newline; an additional empty body line or pipe retains a terminal newline; header line numbers, form metadata, one entry per complete block, unchanged heading scope and support for typed and assignment-to-self entries
Type conversion and retrievalInitially treating values as strings; converting only to the declared type expression; retaining strings without a declaration and converting to the type expression requested at retrieval
Type expression mismatch errorsReporting a mismatch when the declaration differs from the retrieval request, regardless of convertibility; the same error when an undeclared value cannot be converted as requested at retrieval
String interpretation of unsetTreating an unset value received from the parser as equivalent to a zero-length string when a string is requested without a type expression mismatch with a declaration; also retaining the unset state in syntax results
Repeated valuesPreserving every occurrence in source order, including repeated identical values, across fully qualified and relative notation, quotes and type annotations; retaining each occurrence’s type and unset state; no overwriting, deduplication or syntax-level rejection of repeated keys; distinct element boundaries; no value occurrence from a heading; fresh state for each read
Prefix selection (consumer layer)Section 9.1: exact decoded-element prefixes, case and Unicode identity, inclusion of the prefix’s own values and descendants at all depths, exclusion of headings, global source order and duplicates, full and relative paths with preserved boundaries, relative path [] for the prefix itself versus [""] for an empty-named child, original values and type/unset/line metadata without further conversion, an untyped unset prefix value as an empty string with unset true, mixed declared types, empty-prefix selection of all values, distinction from [""], literal *, and an empty collection when no values match
Character encoding and lengthUTF-8, BOM, LF, CRLF, final lines without a line ending, rejection of lone CR; no format-defined fixed upper limits on physical lines, keys, expanded paths, hierarchy depth or the entire file
Output and failureSource order and physical line numbers; empty input; stopping on a notification recipient’s error; no partial results from a collecting interface; no right-hand sides in diagnostics

Checks for type-expression grammar and value conversion will be completed after those rules are decided. Illustrative type names in the specification do not establish valid type names or conversion results.