&ND v2 +++document/meta schemaVersion = "1" id = "aeon-v1-parameterized-object-node-claims" title = "Parameterized Object and Node Claims" description = "Accepted informative design note recording the rationale and boundaries for parameterized object and node claims in AEON v1." family = "aeon" group = "Design Notes" standing = "official" lifecycle = "published" normativity = "informative" license = "CC-BY-4.0" path = "specification/aeon-v1-documentation/parameterized-object-node-claims" order = 80 publish = true keywords = ["AEON", "object", "node", "generic claims", "design note", "container validation"] related = ["aeon-core-v1-value-types", "aeon-core-v1-structure-syntax", "aeon-core-v1-compliance", "aeos-v1"] +++ # Parameterized Object and Node Claims [# parameterized-object-and-node-claims] The normative requirements live in the AEON v1 Value Types Reference, AEON v1 Structure Syntax Reference, AEON v1 Core Compliance, and related appendices. This note records the rationale and boundaries. ## Purpose [# purpose] AEON already supports parameterized container claims for lists and tuples: ~~~$ aeon values:list = [1, 2, 3] point:tuple = (144.9631, -37.8136) ~~~$ These claims are preserved by Core and enforced by schema, profile, convention, or consumer validation. Consolidated AEON v1 extends the same surface to [$ object] and [$ node]. ## [$ object] [# object-t] [$ object] describes an object whose member values are expected to satisfy the given type claim. ~~~$ aeon scores:object = { alice:number = 10 bob:number = 12 } ~~~$ Core preserves [$ object] and validates only that the bound value is an object. It does not enforce member values. ## [$ node] [# node-t] [$ node] has two context-sensitive readings. On ordinary bindings, it claims that the bound node value belongs to a profile, domain, or materialization target: ~~~$ aeon doc:node = , )> child:node = ~~~$ Binding-side [$ node] is deliberately narrower than node-head [$ node]. The argument may be [$ node] itself or a custom profile/domain/materialization target such as [$ html]. Reserved non-[$ node] value datatypes are invalid on ordinary bindings: ~~~$ aeon tag:node = ~~~$ On node heads, it claims the expected type of that node's direct children: ~~~$ aeon title:node = ("Hello world")> ~~~$ Core preserves the claim in both positions. It rejects reserved non-[$ node] binding-side arguments and does not validate node-head children against [$ T]. ## Non-Goals [# non-goals] This does not introduce arbitrary generic reserved datatypes. Invalid Core v1 examples remain invalid: ~~~$ aeon number = 3 string = "body" ("x", 1)> ~~~$ The structural generic family described by this note is: ~~~$ text list tuple object node ~~~$ Other limited parameterized reserved datatypes, such as absence and non-finite domain claims, are defined by the value-types draft when present. They are outside this note's object/node scope. ## Validation [# validation] Validation belongs above Core. For example, AEOS can express object member intent with selectors: ~~~$ json [ { "path": "$.scores", "constraints": { "type": "ObjectNode", "datatype": "object" } }, { "selector": "$.scores.*", "constraints": { "type": "NumberLiteral" } } ] ~~~$ Node child intent can be expressed with SANSA selectors: ~~~$ json [ { "selector": "$.title.*", "constraints": { "type": "StringLiteral" } } ] ~~~$