Undecided matters
This page lists details that the format specification leaves open. Rules defined by the specification remain authoritative; this page does not add format behaviour. The type profile page lists candidate type names and defines the Base64 text representation.
| Item | Undecided details |
|---|---|
| Future format versions | Compatibility and migration policy for versions after the current @dotReg 0.1 declaration in section 1.1 |
| Type names | Which candidate names become standard permitted names, aliases or alternative spellings, and whether type-expression matching is case-sensitive. Simple type names use lowercase English spelling, as specified in section 6.1 |
| Remaining details of type expression grammar | Empty type expressions and the concrete grammar for quotes and escapes within type expressions. Type expressions contain no internal whitespace; symbols and nested parentheses are not prohibited at the syntax level. The type-conversion layer defines the meaning and validity of each type expression (section 6.1) |
| Remaining whitespace rules for type annotations | Whether alignment tabs are allowed between the key and the type expression, or between the closing parenthesis and the colon. Section 6.2 defines alignment whitespace |
| Future escape extensions | Whether to add escape forms beyond the basic notation, \u{H...} and \uXXXX in section 3.4. The Unicode scalar-value range, surrogate-pair handling in the four-digit form, invalid-notation errors and absence of replacement are specified there |
| Unicode character classification | The exact classification of whitespace and control characters in unquoted key elements. Unicode normalisation is not performed, and quoted key elements allow any valid UTF-8 string (section 3) |
| Remaining details of value quoting | Error categories and notification points for decoding errors. Sections 8.2, 8.3 and 8.4 define first-character selection for quoted and literal single-line values, later literal quotes and backslashes, triple-quoted markers and margins, literal pipe detection, form-specific whitespace and escape handling, and explicit empty block state |
| Type-specific decoders | Concrete meanings and conversions for numbers, booleans, lists and other types, and accepted spellings for address and time values. The base64 text representation as standard Base64 is defined in the type profile. Section 8 defines common string decoding, empty-header detection including pipe blocks, explicit empty block values and the equivalence of unset to an empty string when string retrieval is permitted |
| Type-specific interpretation of unset | Treatment in non-string types and the relationship to required fields and defaults. Section 8.1 defines the conversion and retrieval procedure |
| Type expression identity | Matching of type aliases, alternative spellings, compound types and similar expressions. Section 8.1 defines type-mismatch behaviour |
| Failure of conversion to a declared type | Error categories and notification points when conversion to the specified type expression is impossible. Section 8.1 does not permit fallback to another type expression or a string |
| Relationship to schemas | Connecting configuration schemas to declarations and retrieval requests, and handling unknown type names. Section 11 defines the responsibility boundaries |
| APIs and value retention | Concrete API names and native result representations, including boundary-preserving key paths and type expressions; single and indexed retrieval, and aggregate retrieval that requests one common type; retention of conversion results at retrieval; schema API; profile selection method. Section 9 requires preserving all source-ordered occurrences without overwriting. Section 9.1 defines selection of a decoded element prefix’s own values and descendants, full and relative result paths, metadata, ordering and selection without further conversion. Section 11.2 defines syntax result and failure contracts |
| Formatter policy | Whether the notation standard will require a formatter or prescribe a canonical serialization policy. The sample language ports provide limited source-preserving append/update helpers, and the JavaScript sample also has a source formatter; none defines canonical notation |