# AEON v1 Value Types Reference Scope: complete value-kind reference for AEON Core v1, aligned to current TypeScript parser/AES implementation. ## 1. Binding Forms All values are bound as: ```ebnf Binding ::= Key AttributeList? TypeAnnotation? "=" Value ``` Transport vs typed-mode example: ```aeon contact = "John" contact:string = "John" ``` Mode requirements: - `transport` allows untyped non-header bindings and allows custom datatype labels; - `strict` requires a datatype annotation on non-header bindings and rejects custom datatype labels by default; - `custom` requires a datatype annotation on non-header bindings and allows custom datatype labels; - typed modes require datatype annotations on attribute entries that carry values; - typed modes do not require generic args (`arr:list = [...]` is valid); - typed modes do not require datatype clarifiers. Clarifiers are preserved datatype claims whose interpretation belongs to profiles, schemas, or consumers. - typed modes do not require datatype annotations on anonymous list elements, tuple elements, or node children. Implementations MAY still expose an explicit datatype-policy override, but the default semantic behavior is mode-driven. Reserved datatype names in Core are compatibility labels, not full semantic contracts. The datatype label `zdt` is reserved for a possible future zoned datetime type. It is not operational in AEON Core v1, is not an accepted Core v1 datatype family, and does not introduce bracketed zoned-datetime lexical syntax in v1. Anonymous values inside list, tuple, and node-child containers MAY carry a local datatype annotation: ```aeon values:list = [:int32 = 3, :string = "4"] pair:tuple = (:float64 = 10.5, :float64 = 2.0) page:node = , :int32 = 3)> ``` This form is an annotation on an immediate anonymous value, not a binding. It is therefore invalid at document root, invalid inside objects where keyed bindings are required, and invalid when nested as another anonymous typed value: ```aeon :n = 3 // invalid: no container element context a:object = { :n = 3 } // invalid: objects require keyed bindings a:list = [:n = :n = 3] // invalid: typed value cannot wrap another typed value ``` Container typing and anonymous value typing are not equivalent. `numbers:list = [1, 2, 3]` declares an expectation on the container binding, while `values:list = [:int32 = 3, :string = "4"]` annotates individual anonymous elements without changing their order or making them named bindings. In particular: - Core recognizes reserved names such as `int`, `uint`, `int32`, `float64`, `obj`, `envelope`, `trimtick`, `prose`, `sep`, `kadot`, and `sansa`; - Core checks literal-family compatibility only; - stronger semantic enforcement such as integer-only, unsigned-only, width, or range belongs to profile/schema validation layers; - `aeon.gp.profile.v1` and `aeon.gp.schema.v1` are the intended general-purpose baseline for making those stronger meanings operational. ## 1.1 Reserved Datatype Name Table This section lists the accepted datatype-name families used by Core v1. Future-reserved labels, including `zdt`, are intentionally excluded from this table. Interpretation: - `Type` is the canonical name used in examples and docs; - `Alternative names` are short aliases; - `Reserved` are other accepted reserved compatibility names in the same family. ### `string` | Field | Names | | :--- | :--- | | Type | `string` | | Alternative names | none | | Reserved | none | *String value-type names* ### `trimtick` | Field | Names | | :--- | :--- | | Type | `trimtick` | | Alternative names | none | | Reserved | `prose` | *Trimtick value-type names* `prose` is a reserved compatibility label for formatted trimtick text, such as Markdown or other application-level prose formats. Core treats `prose` as the same literal family as `trimtick`; richer format semantics belong to profiles or application contracts. ### `number` | Field | Names | | :--- | :--- | | Type | `number` | | Alternative names | `n` | | Reserved | `int`, `int8`, `int16`, `int32`, `int64`, `uint`, `uint8`, `uint16` | | | `uint32`, `uint64`, `float`, `float32`, `float64` | *Number value-type names* ### `infinity` | Field | Names | | :--- | :--- | | Type | `infinity` | | Alternative names | none | | Reserved | none | *Infinity value-type names* ### `nan` | Field | Names | | :--- | :--- | | Type | `nan` | | Alternative names | none | | Reserved | none | *NaN value-type names* ### `boolean` | Field | Names | | :--- | :--- | | Type | `boolean` | | Alternative names | `bool` | | Reserved | none | *Boolean value-type names* ### `toggle` | Field | Names | | :--- | :--- | | Type | `toggle` | | Alternative names | none | | Reserved | none | *Toggle value-type names* ### `hex` | Field | Names | | :--- | :--- | | Type | `hex` | | Alternative names | none | | Reserved | none | *Hex value-type names* ### `radix` | Field | Names | | :--- | :--- | | Type | `radix` | | Alternative names | none | | Reserved | `decimal`, `radix2`, `radix6`, `radix8`, `radix12` | *Radix value-type names* ### `encoding` | Field | Names | | :--- | :--- | | Type | `encoding` | | Alternative names | none | | Reserved | `base64`, `embed`, `inline` | *Encoding value-type names* ### `date` | Field | Names | | :--- | :--- | | Type | `date` | | Alternative names | none | | Reserved | none | *Date value-type names* ### `time` | Field | Names | | :--- | :--- | | Type | `time` | | Alternative names | none | | Reserved | none | *Time value-type names* ### `datetime` | Field | Names | | :--- | :--- | | Type | `datetime` | | Alternative names | none | | Reserved | `wtc` | *Datetime value-type names* ### `sep` | Field | Names | | :--- | :--- | | Type | `sep` | | Alternative names | none | | Reserved | `kadot` | *Separator value-type names* ### `sansa` | Field | Names | | :--- | :--- | | Type | `sansa` | | Alternative names | none | | Reserved | none | *SANSA value-type names* `sansa` is the reserved datatype label for SANSA address literals. SANSA means Semantic Address NameSpace Abstraction. In strict mode, SANSA address literal values are written with the `:sansa` datatype annotation. Core validates and preserves the accepted literal surface; resolution, selector expansion, authorization, and qualifier meaning belong to consumers. ### `object` | Field | Names | | :--- | :--- | | Type | `object` | | Alternative names | `obj`, `o` | | Reserved | `envelope` | *Object value-type names* ### `list` | Field | Names | | :--- | :--- | | Type | `list` | | Alternative names | none | | Reserved | none | *List value-type names* ### `tuple` | Field | Names | | :--- | :--- | | Type | `tuple` | | Alternative names | none | | Reserved | `triple` | *Tuple value-type names* ### `node` | Field | Names | | :--- | :--- | | Type | `node` | | Alternative names | none | | Reserved | none | *Node value-type names* ### `null` | Field | Names | | :--- | :--- | | Type | `null` | | Alternative names | none | | Reserved | `!none`, `!notSet`, `!notApplicable`, `!tombstone` | *Null value-type names* ## 2. Value Kind Catalog | Family | Surface | Transport Example | Strict Example | AES `value.type` | | :--- | :--- | :--- | :--- | :--- | | String | `"..."`, `'...'`, `` `...` `` | `name = "John"` | `name:string = "John"` | `StringLiteral` | | Trimtick | `` >`...` `` through `` >>>>`...` `` | `` note = >>`...` `` | `` note:trimtick = >>`...` `` | `StringLiteral` | | Number | `42`, `3.14`, `.5`, `1e3`, `1_000` | `count = 42` | `count:number = 42` | `NumberLiteral` | | Infinity | `Infinity`, `-Infinity` | `top = Infinity` | `top:infinity = Infinity` | `InfinityLiteral` | | NaN | `NaN`, `-NaN` | `bad = NaN` | `bad:nan = NaN` | `NaNLiteral` | | Null | `!none`, `!notSet`, `!"..."` | `missing = !none` | `missing:null = !none` | `NullLiteral` | | Boolean | `true`, `false` | `flag = true` | `flag:boolean = true` | `BooleanLiteral` | | Toggle | `yes`, `no`, `on`, `off` | `state = on` | `state:toggle = on` | `ToggleLiteral` | | Hex | `#ff00aa` | `color = #ff00aa` | `color:hex = #ff00aa` | `HexLiteral` | | Radix | `%1011`, `%19.9900` | `bits = %1011` | `bits:radix[2] = %1011` or `price:decimal = %19.9900` | `RadixLiteral` | | Encoding | `&QmFzZTY0IQ==` | `payload = &QmFzZTY0IQ==` | `payload:base64 = &QmFzZTY0IQ==` | `EncodingLiteral` | | Date | `2025-01-01`, `2024-02-29` | `d = 2025-01-01` | `d:date = 2025-01-01` | `DateLiteral` | | Time | `09:`, `09:30`, `09:30Z`, `09:+02:00`, `09:30+02:00`, `09:30:00`, `09:30:00Z` | `t = 09:30:00` | `t:time = 09:30:00Z` | `DateTimeLiteral` | | DateTime | `2025-01-01T09`, `2025-01-01T09Z`, `2025-01-01T09+02:00`, `2025-01-01T09:30:00Z` | `ts = 2025-01-01T09:30:00Z` | `ts:datetime = 2025-01-01T09:30:00Z` | `DateTimeLiteral` | | WTC | `2025-01-01T00:00:00Z&Australia/Sydney`, `2025-01-01T09&Europe/Belgium/Brussels`, `2025-01-01T09:30Z&Local`, `2035-01-01T09:00&-36.7590183/144.2826718` | `z = 2025-01-01T00:00:00Z&Australia/Sydney` | `z:wtc = 2025-01-01T00:00:00Z&Australia/Sydney` | `WTCDateTimeLiteral` | | Separator Literal | `^300x250` | `size = ^300x250` | `size:sep["x"] = ^300x250` | `SeparatorLiteral` | | SANSA Address | `$.path`, `?.path`, `$.items.*.sku` | `path:sansa = $.contact.name` | `selector:sansa = $.inventory.items.*.sku` | `SansaAddressLiteral` | | Object | `{ ... }` | `user = { name = "John" }` | `user:object = { name:string = "John" }` | `ObjectNode` | | List | `[ ... ]` | `arr = [1,2,3]` | `arr:list = [1,2,3]` or `arr:list = [1,2,3]` | `ListNode` | | Tuple | `( ... )` | `point = (10,20)` | `point:tuple = (10,20)`, `edge:triple = ("a","b","c")` | `TupleLiteral` | | Node | `` / `` | `view = ` | `view:node = ` | `NodeLiteral` | | Clone Ref | `~path` | `b = ~a` | `b:number = ~a` | `CloneReference` | | Pointer Ref | `~>path` | `alias = ~>a` | `alias:object = ~>a` | `PointerReference` | *AEON value-kind catalog* ## 3. Literal Details ## 3.1 String Examples: ```aeon name = "John" alias = 'J' multiline = `Hello World` ``` Escape sequences for quoted strings (`"` and `'`): - `\\`, `\"`, `\'`, ``\` `` - `\n`, `\r`, `\t`, `\b`, `\f` - `\uXXXX` - `\u{X...}` (1-6 hex digits, max `10FFFF`) Nuances: - backtick strings are raw strings and may span multiple lines; - non-backtick strings cannot contain raw newline; - quoted Unicode escapes must decode to valid Unicode scalar values; - `\uXXXX` high-surrogate forms are legal only when immediately followed by a valid `\uXXXX` low-surrogate form in the same decoded sequence; - lone high-surrogate and lone low-surrogate escapes are illegal; - malformed braced Unicode escapes, incomplete Unicode escapes, non-hex escape payloads, and out-of-range code points are illegal; - invalid escapes fail closed with deterministic invalid-escape diagnostics. Examples: ```aeon ok1 = "\u0041" ok2 = "\u{41}" ok3 = "\uD83D\uDE00" ``` ```aeon bad1 = "\uD800" bad2 = "\uDC00" bad3 = "\u{" bad4 = "\u{110000}" bad5 = "line1 line2" ``` Canonical notes: - canonical single-line strings emit double-quoted strings with minimal escaping; - canonical multiline strings may emit as trimticks using canonical indentation. AES: - `StringLiteral` with `value`, `raw`, and `delimiter`. ## 3.2 Trimtick Trimticks are a distinct multiline string form. They still produce `StringLiteral` values in AES, but unlike ordinary strings they apply an explicit trimming step to the raw backtick payload. Because of that, they are documented separately here instead of being treated as just another spelling of `string`. Examples: ```aeon note:trimtick = >` one two ` note:trimtick = >>` one two ` body:prose = >` # Title Markdown-ish content. ` ``` Syntax: - trimticks start with a contiguous `>` through `>>>>` marker; - the marker must be followed by a backtick string opener; - spaces between the contiguous marker and the backtick opener are accepted; - the marker itself may not be split. Trimming rules: - trim the first empty line after the opener, if present; - trim trailing empty lines before the closer; - inspect the remaining non-empty lines to determine common left indentation; - remove that indentation according to the marker's tab policy; - preserve trailing whitespace on non-empty lines; - preserve interior blank lines as blank lines; - if all remaining lines are empty, the resulting value is the empty string. Marker-width policy: - `` >` ``: spaces-only indentation analysis; tabs remain payload; - `` >>` ``: tabs normalize to width `2` for indentation analysis; - `` >>>` ``: tabs normalize to width `3` for indentation analysis; - `` >>>>` ``: tabs normalize to width `4` for indentation analysis. Single-line trimticks are valid and behave like ordinary raw backtick content, because there is no multiline gutter to remove. Canonical notes: - canonical multiline semantic strings emit as spaces-only trimticks; - canonical output normalizes the indentation gutter to spaces only. - canonical output may collapse trimticks to ordinary string literals when the normalized value is rendered in an inline context; - one-line normalized trimticks in inline containers canonically emit as ordinary double-quoted strings; - multiline trimtick values rendered inside inline object or attribute forms canonically emit as escaped double-quoted strings rather than multiline trimtick blocks; - multiline trimtick blocks are preserved in canonical output when the enclosing canonical layout is multiline. AES: - `StringLiteral` with trimtick parser metadata preserved. ## 3.3 Number Examples: ```aeon count = 42 ratio = 3.14e-2 half = .5 large = 1_000_000 ``` Nuances: - underscore separators are accepted only between digits and normalized in parsed numeric value; - leading-dot decimals such as `.5`, `-.5`, and `+.5` are accepted; - invalid underscore forms include leading (`_100`), trailing (`100_`), consecutive (`100__000`), and adjacency to non-digits; - numeric width/precision are not core-level semantics. Canonical notes: - underscore separators removed; - canonicalization of `:number` values is value-normalizing while preserving the broad representation family (`integer`, `decimal`, `exponent`); - leading-dot decimals normalize to an explicit zero (`.5` → `0.5`, `-.5` → `-0.5`); - decimal-family values trim redundant trailing fractional zeroes, but retain at least one fractional digit (`10.00` → `10.0`); - exponent-family values normalize to lowercase `e` and trim redundant exponent sign and leading exponent zeroes (`1.0E+03` → `1e3`); - zero follows the same family rule rather than a one-off special case: integer zero canonically emits as `0`/`-0`, decimal zero as `0.0`/`-0.0`, and exponent zero as `0e0`/`-0e0`. AES: - `NumberLiteral` (`value` normalized, `raw` preserved). - `NumberLiteral` is finite-only. Underscore examples: ```aeon n1 = 100_000 // valid n2 = _100_000 // invalid n3 = 100__000 // invalid n4 = 100_000_ // invalid ``` ## 3.3.1 Infinity Examples: ```aeon top = Infinity bottom = -Infinity ceiling:infinity = Infinity floor:infinity = -Infinity limit:infinity = Infinity ``` Nuances: - `InfinityLiteral` is a distinct literal family from `NumberLiteral`; - `infinity` is a non-finite domain claim: Core preserves the parameter and treats the value as an infinity literal, while schema, profile, or consumer validation may interpret the claimed domain; - accepted surface forms are exactly `Infinity` and `-Infinity`; - `+Infinity`, `NaN`, `-NaN`, `+NaN`, `inf`, and lowercase aliases are invalid; - explicit `:infinity` compatibility is enforced in all modes; - `:number` remains finite-only and rejects `InfinityLiteral`. Canonical notes: - canonical output preserves `Infinity` and `-Infinity` exactly; - invalid spellings have no canonical form. AES: - `InfinityLiteral` with `value` and `raw` equal to `Infinity` or `-Infinity`. ## 3.3.2 NaN Examples: ```aeon bad = NaN signed = -NaN badValue:nan = NaN signedValue:nan = -NaN badReading:nan = NaN ``` Nuances: - `NaNLiteral` is a distinct literal family from `NumberLiteral`; - `nan` is a non-finite domain claim: Core preserves the parameter and treats the value as a NaN literal, while schema, profile, or consumer validation may interpret the claimed domain; - accepted surface forms are exactly `NaN` and `-NaN`; - `+NaN`, `Infinity`, `-Infinity`, lowercase aliases, and shorthand forms are invalid; - explicit `:nan` compatibility is enforced in all modes; - `:number` remains finite-only and rejects `NaNLiteral`. Canonical notes: - canonical output preserves `NaN` and `-NaN` exactly; - invalid spellings have no canonical form. AES: - `NaNLiteral` with `value` and `raw` equal to `NaN` or `-NaN`. ## 3.3.3 Null Examples: ```aeon missing = !none state = !notSet deleted = !tombstone reservationDate:null = !"postponed" nextRetry:null = !none ``` Nuances: - `NullLiteral` is a distinct literal family from `StringLiteral` and `NumberLiteral`; - `null` is an absence-domain claim: Core preserves the parameter and treats the value as a null literal, while schema, profile, or consumer validation may interpret the absent value's expected domain; - reserved sentinel forms are exactly `!none`, `!notSet`, `!notApplicable`, and `!tombstone`; - custom null reasons must use a quoted string form after `!`; - implementation-specific null distinctions should use quoted custom reasons such as `!"js.undefined"` rather than a separate null convention; - quoted custom reasons must decode to a non-empty, non-ASCII-whitespace-only string; - quoted custom reasons must not decode to any reserved null sentinel name; - collision checks are performed on decoded strings without Unicode normalization; - explicit `:null` compatibility is enforced in all modes. Canonical notes: - reserved sentinels preserve their exact spellings; - quoted custom reasons canonicalize using ordinary AEON string canonicalization after `!`; - canonicalization must not rewrite reserved sentinels into quoted reasons or vice versa. AES: - `NullLiteral` with `mode`, `value`, and `raw`. ## 3.4 Boolean Examples: ```aeon enabled = true // valid boolean literal visible = false // valid boolean literal show = TRUE // invalid as boolean literal (not a boolean token) activate = 'true' // valid AEON, but string literal (not boolean) pass = 1 // valid AEON, but number literal (not boolean) ``` Nuances: - lowercase `true`/`false` keywords. - explicit `:boolean` compatibility is enforced in both transport and strict. Canonical notes: - Canonical boolean tokens are lowercase true and false. AES: - `BooleanLiteral`. ## 3.5 Toggle Examples: ```aeon state = on // valid toggle literal state:toggle = off // valid toggle literal state:toggle = true // invalid ``` Nuances: - lexical forms: `yes`, `no`, `on`, `off`; - untyped toggle literals are allowed in transport mode; - in strict mode, untyped toggle literals must be annotated with `:toggle`; - non-`:toggle` custom datatype aliases such as `:myToggle` remain invalid even when general custom datatypes are otherwise enabled; - machine-readable surfaced `ToggleLiteral.value` remains lexical (`yes`, `no`, `on`, `off`); - finalized JSON materializes toggle literals as booleans. AES: - `ToggleLiteral`. ## 3.6 Hex Examples: ```aeon color = #ff00aa color:hex = #ff00aa ``` Nuances: - parsed as hex literal payload without `#` in `value`; - surfaced machine-readable `value` is the payload-only form, while `raw` preserves the original sigiled source token; - `_` is visual spacing only and is valid only between hex digits; - leading, trailing, and consecutive `_` forms are invalid; - `HexLiteral` is distinct from `RadixLiteral`. `#ff` is not the same literal family as `%ff`, even when a radix profile or datatype annotation uses base 16; - Core does not assign color, byte-array, identifier, numeric, or hash semantics to hex values; those meanings belong to profiles, schemas, or consumers. AES: - `HexLiteral`. ## 3.7 Radix Examples: ```aeon bits = %1011 bits:radix[2] = %1011 ``` Nuances: - payload captured without `%`. - radix literals are number-like rather than encoding-like; - `radix[base]` is informative metadata rather than a generic type parameter; - optional radix base metadata uses datatype clarifier syntax, for example `radix[2]`, `radix[10]`, or `radix[16]`; - Core syntax accepts numeric clarifier values and preserves them; profile/schema layers decide whether a numeric clarifier is a meaningful radix base; - `aeon.gp.profile.v1` requires exactly one integral numeric clarifier from `2` through `64` when `radix` carries an explicit base, and rejects string, empty, multiple, fractional, or out-of-range radix clarifiers; - spaces around the radix base inside brackets are allowed in AEON source, but the integer itself must be contiguous; - radix base forms with leading zeroes, non-decimal payloads, empty brackets, repeated bracket lists, or values outside `2..64` are invalid when a GP/AEOS layer activates radix-base semantics; - `decimal` is a reserved alias for `radix[10]`; - reserved aliases such as `radix2`, `radix6`, `radix8`, and `radix12` remain accepted as shorthand; - optional leading sign `+` or `-` is allowed only once at the start of the payload; - radix payload digits are `0-9`, `A-Z`, `a-z`, `&`, and `!` in that order; - `.` is an optional radix decimal point and may appear at most once; - radix decimals may omit the integer part when there is at least one radix digit after the dot (for example `%.3`, `%-.3`, `%+.1`); - if present, the radix decimal point must still be followed by at least one radix digit; - `_` is visual spacing only and is valid only between radix digits; - radix payload leading zeroes are allowed and preserved as part of the represented digit sequence (for example `%00100101`); - `/` and `=` are not valid radix payload characters; - lexical acceptance is not base-specific radix validity; - base-specific digit checks still belong downstream for implementation/profile/schema enforcement; - generic forms such as `radix<2>` are invalid; radix base metadata uses brackets. - `radix16` is not a reserved Core v1 shorthand. Use `radix[16]` for radix-family base-16 values. - `radix[16]` remains distinct from `hex`; it produces `RadixLiteral`, while `hex` produces `HexLiteral`. Canonical notes: - canonicalization of `:radix[...]` values is representation-preserving rather than value-normalizing; - `_` separators are removed from canonical radix output; - the remaining digit sequence, decimal-point placement, and leading-zero width are otherwise preserved. AES: - `RadixLiteral`. ## 3.8 Encoding Examples: ```aeon payload = &QmFzZTY0IQ== payload:base64 = &QmFzZTY0IQ== code:encoding["base58"] = &FFF payload:embed = &QmFzZTY0IQ== payload:inline = &QmFzZTY0IQ== ``` Nuances: - encoding literals use `&` as the literal prefix; - payload captured without `&`; - `encoding`, `base64`, `embed`, and `inline` all bind to the same `EncodingLiteral` family in Core v1; - encoding/base64 payload accepts the Base64URL alphabet (`A-Za-z0-9-_`) with optional trailing `=` padding; - standard base64 alphabet characters `+` and `/` are invalid in AEON encoding/base64 payloads; - canonical encoding/base64 rendering preserves the accepted Base64URL payload spelling, including trailing `=` padding; - lexical acceptance is not encoding-family validity; - `encoding` does not always mean decoded Base64 data. Core preserves an encoded lexical payload; decoding, byte identity, media type, and text interpretation belong to profiles, schemas, or consumers; - `aeon.gp.profile.v1` allows `encoding`, `inline`, and `embed` to carry exactly one string clarifier as an encoding-name claim, for example `encoding["base58"]`; - `base64` is an encoding-family compatibility label, not a radix-family label. `base64` is not equivalent to `radix[64]`; - `embed` and `inline` are reserved compatibility labels over the same `EncodingLiteral` family; Core does not assign media, resource-loading, or inline-expansion behavior to them; - Shared Value Semantics may define naïve payload order over the preserved encoded payload characters, but decoded-byte ordering, decoded-text ordering, media ordering, or hash ordering belongs to profiles, schemas, or consumers; - `a = &aa=` is unambiguous in current lexer, because the second `=` remains part of the encoding token rather than being reinterpreted as assignment. AES: - `EncodingLiteral`. ## 3.9 Date / Time / DateTime / WTC Examples: ```aeon start:date = 2025-01-01 at:time = 09:30:00 utc:time = 09:30:00Z local:time = 09:30:00+02:40 ts:datetime = 2025-01-01T09:30:00Z z:wtc = 2025-01-01T00:00:00Z&Australia/Sydney localTime:wtc = 2025-01-01T00:00:00&Local // WTC local time convention geoTime:wtc = 2035-01-01T09:00&-36.7590183/144.2826718 ``` Nuances: - parser emits `DateLiteral` for date-only token; - parser emits `DateTimeLiteral` for time and datetime-family tokens and `WTCDateTimeLiteral` for WTC tokens with an `&temporal-reference` suffix; - standalone `time` is part of Core v1 and follows ISO 8601 time forms; - date, time, and datetime literal recognition includes intrinsic calendar/clock range validation; - zone suffixes (`Z`, `+hh:mm`, `-hh:mm`) may attach to valid reduced-precision time forms already admitted by Core v1, such as `09:` and `09:30`; - `datetime` extends that same reduced-precision rule after the `T`, so forms such as `2025-01-01T09Z`, `2025-01-01T09+02:00`, and `2025-01-01T09:30Z` are valid; - WTC extends the same reduced-precision datetime bases with a temporal reference suffix, so forms such as `2025-01-01T09&Europe/Belgium/Brussels`, `2025-01-01T09Z&Europe/Belgium/Brussels`, `2025-01-01T09:30Z&Local`, and `2035-01-01T09:00&-36.7590183/144.2826718` are valid `wtc` literals; - WTC temporal references may contain `/`, `_`, `-`, `+`, and `.` when used as part of a contiguous reference, so named timezone references such as `America/Port-au-Prince`, `GB-Eire`, `Etc/GMT-1`, and `Etc/GMT+1`, plus geographic references such as `-36.7590183/144.2826718`, are valid reference payloads; - comment markers do not begin inside a contiguous WTC temporal-reference payload; forms such as `Europe//Brussels` and `Europe/*Brussels*/` are invalid reference payloads, not shortened values followed by comments; - uppercase `Z` is the Core v1 UTC marker form; lowercase `z` is not a temporal literal marker; - invalid ranges such as `2025-13-40`, `2025-02-29`, `24:00`, `99:99`, and `23:59:60` are not temporal literals in Core v1; - strict datatype compatibility treats `:time` and `:datetime` as `DateTimeLiteral`-compatible and `:wtc` as `WTCDateTimeLiteral`-compatible; - local-time WTC convention is `...&Local` (for example `2025-01-01T00:00:00&Local`); - WTC preserves whether the temporal value is instant-anchored (`...Z&reference`) or civil-time-anchored (`...&reference`); the temporal value and temporal reference together form the temporal context; - WTC is represented as DateTime token family in AST/AES. AES: - `DateLiteral` or `DateTimeLiteral`. ## 3.10 Separator Literal (`^...`) Examples: ```aeon size:sep["x"] = ^300x250 dimensions:sep["w", "h", "d"] = ^300w400h200d semver:kadot = ^3.14.15 ip1:sep = ^127.0.0.1 ip2:sep["."] = ^127.0.0.1 parts:sep["|"] = ^"hello world"|"this, [is] fine" psv:sep["|"] = ^"id"|"name"|"phone" ``` Datatype clarifier grammar: ```ebnf TypeAnnotation ::= ":" TypeName GenericArgs? Clarifier? Clarifier ::= "[" ClarifierValue ("," ClarifierValue)* "]" ClarifierValue ::= StringLiteral | NumberLiteral ``` Clarifier rules (implementation-aligned): - a datatype may carry at most one clarifier list; - a clarifier list contains one or more string or numeric values; - separator characters are string clarifiers, for example `sep["x"]`; - radix bases are numeric clarifiers, for example `radix[16]`; - repeated bracket lists such as `sep["x"]["y"]` are invalid; - type-specific meaning and compatibility belong to profiles and AEOS. Depth/policy: - parser option `maxSeparatorDepth` (core option `maxSeparatorDepth`); - default lock: `1`; - capability floor target: up to `8` via policy configuration. Payload grammar: - separator payload begins immediately after `^` and is read as one or more contiguous segments; - each segment is either a raw segment or an ordinary quoted string segment; - raw segments may use only `A-Z`, `a-z`, `0-9`, and `! # $ % & * + - . : ; = ? @ ^ _ | ~ < >`; - quoted segments use ordinary AEON single-quoted or double-quoted string lexical rules; - backtick strings are not valid separator segments; - no raw separator escapes are defined; - outside quoted segments, whitespace, `\\`, `/`, `,`, and closing container boundaries are not payload characters; - comment syntax resumes normally once a separator payload ends outside quoted segments. - `:sep` may bind separator literals with or without explicit clarifiers. - `:kadot` may bind unparameterized separator literals. The intended kadot shape is dot-separated numeric segments, for example `ip:kadot = ^198.0.126.255` or `semver:kadot = ^3.14.15`, but Core only enforces the separator-literal family; stricter shape validation belongs to schema/profile layers. - Core does not assign IP, semantic-version, dimension, table, product-code, or other domain meaning to separator literals. - Shared Value Semantics may define naïve separator order over the canonical separator payload. Naïve order does not split payloads, even when datatype clarifiers such as `["."]` are present. - Domain ordering such as version order, numeric IP address order, or aspect-ratio order belongs to profiles, schemas, or consumers. - Datatype clarifiers are preserved claims. `aeon.gp.profile.v1` declares the GP interpretation of `sep`/`separator` string clarifiers as separator characters and rejects non-string separator clarifiers. Datatypes without an active GP clarifier rule, or GP entries with `clarifiers = "none"`, do not accept explicit clarifier lists under the GP profile. Core-only processing preserves clarifier text but does not activate splitting or ordering from those clarifiers. Profile-defined splitting or ordering should use them only when the consumer trusts the source, validates the claim against the payload, or supplies separator structure from trusted configuration. AES: - `SeparatorLiteral` with raw payload preserved. ## 3.11 SANSA Address Literal SANSA means **Semantic Address NameSpace Abstraction**. Examples: ```aeon path:sansa = $.contact.name context:sansa = ?.name selector:sansa = $.inventory.items.*.sku deepSelector:sansa = $.inventory.** attribute:sansa = $.contact.name.@.unit pattern:sansa = $.items.("item?*").sku qualified:sansa = $.result:number|nan external:sansa = $.["john"].isLocatedAt.["Brussels"] ``` Core role: - `:sansa` marks a value as a SANSA address literal; - strict mode requires the reserved `:sansa` datatype annotation for SANSA address literal values; - the literal may express an exact path or selector; - AEON Core validates and preserves the address form it accepts; - AEON Core does not resolve the address, expand selectors, interpret qualifiers, or authorize access to any target. - SANSA member selectors describe semantic traversal rather than object traversal. - AEON-backed consumers may resolve SANSA literals against AEON bindings and canonical paths, but `:sansa` values are not limited to AEON path domains. - A SANSA literal may address another semantic namespace, such as an RDF-like graph, database, service resource tree, filesystem namespace, or runtime object graph, when a consumer exposes that namespace. - Exact address-expression identity, canonical target identity, selector equivalence, and resolved Binding Set equality are distinct semantic questions. Lexical boundary: - a SANSA literal begins where the value begins; - it continues until ASCII whitespace, a comma, or a line break that closes the value in the current AEON context; - quoted SANSA segments and qualifier arguments use SANSA/AEON quoted payload rules where the SANSA grammar allows them. Reference boundary: - `target:sansa = $.contact.name` stores an address as data; - `copy = ~contact.name` is an AEON clone reference; - `pointer = ~>contact` is an AEON pointer reference. These forms are related by address syntax, but they are not interchangeable. AEON reference legality applies only to `~` and `~>` values. AES: - `SansaAddressLiteral` with parsed address structure and/or source literal preserved by the implementation. ## 4. Structured Values Core preserves structural representation for objects, lists, tuples, and nodes. Shared semantics are layered on top of that representation: - object member order is preserved but is not semantically significant in the GP profile; - list element order and index-addressability are preserved; - tuple position and arity are preserved; - node tags, attributes, child order, and indexed child slots are preserved; - structural equality and mutation compatibility are defined by Shared AEON Value Semantics and any active schema/profile authority; - structural ordering has no Core default. ## 4.1 Object Example: ```aeon user = { id:number = 1 name:string = "John" } ``` AES: - `ObjectNode`. Reserved object aliases: - `:object` - `:obj` - `:o` - `:envelope` All of these aliases perform the same Core compatibility check: the bound value must be an object. Core does not attach extra semantics to `:envelope`; it is an ordinary object alias that conventions may reuse. Parameterized object claims: ```aeon scores:object = { alice:number = 10 bob:number = 12 } ``` `object` is a preserved claim that object member values are expected to satisfy `T`. Core validates only that the bound value is an object and preserves the full datatype annotation. Member-value validation belongs to AEOS, profiles, conventions, or trusted consumer logic. Example: ```aeon close:envelope = { integrity = { alg:string = "sha-256" } } ``` Convention note: - GP security conventions recommend `close:envelope` as the standard security-envelope spelling. - That recommendation is convention-level only; Core does not privilege the key `close`. ## 4.2 List Examples: ```aeon arr = [1,2,3] arr:list = [1,2,3] arr:list = [1,2,3] ``` Nuances: - strict requires datatype presence, not generic args; - generic args are optional syntax and not enforced by core semantic typing rules. - Core v1 reserves generic arguments for `list`, `tuple`, `object`, `node`, `null`, `nan`, and `infinity`. - nested generic type annotations are valid surface syntax and count against `max_generic_depth`. - list elements may carry local anonymous datatype annotations with `:type = value`. AES: - `ListNode`. ## 4.3 Tuple Examples: ```aeon point = (10,20) point:tuple = (10,20) point:tuple = (10,20) edge:triple = ("subject","predicate","object") ``` Nuances: - tuple/list distinction is preserved in AST/AES; - `triple` is a semantic alias of `tuple` and introduces no additional runtime behavior; - strict does not require tuple generic args. - tuple elements may carry local anonymous datatype annotations with `:type = value`. AES: - `TupleLiteral`. ## 4.4 Node Examples: ```aeon content = , "world")>)> content:node = , "world")>)> doc:node = , )> child:node = icon:node = title:node = ("Hello world")> ``` Nuances: - node forms are `` for nodes with children and `` for empty nodes; - empty-node shorthand `` is exactly equivalent to ``; - child-bearing node forms require the closing `>`; `` are transport/custom forms, not strict forms; - `binding:node` is a preserved profile/domain/materialization-target claim about the bound node value; - binding-side `node` accepts `T = node` or a custom profile/domain/materialization target such as `html`; - binding-side `node`, `node`, and other reserved non-`node` value datatype arguments are invalid because child-content claims belong on node heads; - `(...)>` is a preserved child-content claim about that node head's children; - Core validates the binding-side reserved-argument rule, validates that `node` binds or annotates a node value, and preserves the full datatype annotation; - child list may contain mixed value kinds; - node children may carry local anonymous datatype annotations with `:type = value`; - nodes are values; node children do not become independent top-level named bindings, but ordered child slots use indexed canonical paths. AES: - `NodeLiteral`. ## 5. References Examples: ```aeon a = 1 b = ~a c = ~>a item = ~$.items[0] meta = ~a.@.ns ``` Nuances: - clone (`~`) and pointer (`~>`) are distinct and preserved; - ASCII inter-token whitespace may appear between the reference sigil and the following path, but canonical formatting removes it; - attribute selectors are valid in reference paths; - legality checks (missing/forward/self) are core-owned; - reference-form identity compares the reference kind and canonical exact target path; - evaluating the referenced target value without rewriting the source value is a read-only consumer operation, conceptually `follow(reference)`, not a Core parse operation; - resolving a reference is a separate materialization/substitution operation that may inline, clone, alias, or preserve an explicit runtime reference according to consumer policy; - consumers that follow or resolve references must preserve the original reference form in AES or other representation-preserving outputs. AES: - `CloneReference` or `PointerReference`. ## 6. EBNF Summary ```ebnf Value ::= Literal | Reference | Object | List | Tuple | Node Literal ::= String | Number | Boolean | Toggle | Hex | Radix | Encoding | Date | DateTime | SeparatorLiteral Reference ::= "~" RefPath | "~>" RefPath Object ::= "{" (Binding)* "}" List ::= "[" (Value ("," Value)*)? "]" Tuple ::= "(" (Value ("," Value)*)? ")" Node ::= "<" Identifier AttributeList? TypeAnnotation? "(" (Value ("," Value)*)? ")" ``` ## 7. Canonicalization and Drift Controls Implementers should align with: - [`appendices/appendix-canonical-form`](./appendix-canonical-form-v1.md) - [`appendices/appendix-aes`](./appendix-aes-v1.md) - [`AEON-v1-compliance`](./aeon-core-v1-compliance.md) This page is intentionally implementation-cross-checked to reduce inter-implementation drift. --- ## Related documents - [AEON Specification v1](./aeon-core-v1.md) - [AEON v1 Structure Syntax Reference](./aeon-core-v1-structure-syntax.md) - [AEON v1 Addressing, SANSA Literals, and References Reference](./aeon-core-v1-addressing-references.md) - [AEOS Specification v1](./aeos-v1.md) - [Parameterized Object and Node Claims](./aeon-v1-parameterized-object-node-claims.md)