Text

Core primitive scalar representing Unicode text (a JSON string). - Authoring & wrappers: detail: > Instances may be authored as scalar sugar (myField: "hello") or as the wrapped form (myField: { value: "hello" }). Canonical hashing uses the wrapped form (§8.2.2). This type itself does NOT declare a `value` field: `value` is the language wrapper for instance payloads (§2.1); putting `value` on the type would fix a concrete payload on the type object (a fixed-value invariant, §4.1), which is not intended. - Length semantics: detail: > minLength/maxLength count Unicode code points, not bytes and not UTF-16 code units. A character outside the BMP (e.g., "𝄞") counts as 1. A CRLF pair counts as 2 code points ("\r" + "\n"). - Regex dialect: detail: > `pattern` uses ECMA-262 syntax. Matching is not implicitly anchored; use ^…$ for whole-string matches. - Canonical JSON vs content: detail: > RFC 8785 canonicalization affects only JSON encoding (escapes, key ordering of parent objects). It NEVER changes the underlying code-point sequence. Equality (including `enum`) compares the parsed scalar value. - Unicode normalization: detail: > Processors MUST NOT normalize Text by default (no NFC/NFD folding). The exact code-point sequence is preserved. Any optional normalization may occur only via profile-specific preprocessing in `blue` (§7.1). - Case/locale: detail: > No case folding or locale-sensitive collation is implied in Part I. Perform such transforms explicitly during preprocessing (profile- dependent) or in higher-level contracts (Part II). - Empty string: detail: > The empty string "" is valid unless restricted by schema (e.g., minLength > 0). - Escapes & line breaks: detail: > JSON escapes (\uXXXX, \" \\ \n \r \t \b \f) are authoring/encoding details only; after parsing they contribute their code points to length and pattern checks. - Applicable schema: detail: > §5.5 string constraints: minLength, maxLength, pattern.