CatalogDefinition

A collection of component and function definitions that a surface renders against.

components and functions hold their definitions keyed by type name.

schemaKeywords carries $schema, $id, and $defs through unread. A definition may reference #/$defs/..., so dropping them would leave a re-encoded catalog — an inline one carried in RendererCapabilitiesV1.inlineCatalogs, say — with unresolvable references.

The specification's "Catalog Entity Naming Rules" are an invariant of this type rather than of its serializer, and checkEntityNames is where they are stated. A catalog reaches a checker three ways and only one of them decodes, so a rule enforced on the way in from the wire would leave dev.ynagai.a2ui.core.validation.CatalogValidator.of and dev.ynagai.a2ui.core.validation.CompositionValidator — both of which take definitions directly — holding catalogs no wire catalog could be.

A name this type accepts is a name a formatString expression can call. The rule enforced here is the specification's, answered from the derived XID_Start and XID_Continue tables, and the expression parser behind the formatString function judges the names inside a ${…} by the same tables -- it is mentioned here because this is where a name is accepted. 0.1.0 shipped with the parser on an approximation of its own that disagreed in both directions (#45).

That invariant is established at construction, which is all a constructor can do: the maps passed to it must not be retained and mutated by the caller. components, functions and schemaKeywords are held as given rather than copied, so a caller that keeps a MutableMap it passed in and writes to it afterwards puts names into this catalog that the check never saw, and the serializer will then emit them. Pass a map this type can own — a literal, a buildMap, or toMap() on anything still reachable from the caller. Decoded catalogs are unaffected: the serializer builds their maps and hands over the only reference.