0019: URI, URI-reference and UUID sample conventions
RFC 9880 Appendix C.2 gives format an abstract information-level meaning. uri and uri-reference refer to RFC 3986; uuid refers to RFC 9562. The URI and UUID sample contract supplies conventional JSON inputs and the scope of established conclusions, following ADR 0007: Generated SDF and sample JSON, ADR 0015: Bounded value equality in a resolved data context and ADR 0016: Selected samples with explicit admission and coverage.
FullBaseline establishes these named model interpretations independently of actual operands. This M049 assessment does not establish scheme-specific admission, target identity or general comparator capability. A constant still needs its actual contextual denotation and adopted equality. Recognizing a model selector alone does not consult the sample representation facts.
The URI representation check assesses generic RFC 3986 syntax: URI requires a scheme and permits a fragment, while URI-reference also permits relative and empty forms. Fragment-free absolute-URI is a separate production. A successful generic check establishes its stated representation conclusion, not full abstract-format admission when needed scheme validity is unavailable. Scheme-bearing positive admission requires an established compatible meaning including applicable scheme-specific requirements; unsupported needed scheme meaning stays undetermined rather than being rejected by an allowlist. Relative-reference expression admission requires no target resolution, while any needed base or inherited scheme meaning stays explicit. No implicit IRI conversion changes the conventional channel. RFC 3986 Sections 1.1.1 and 4.1 distinguish generic and scheme-specific scopes. RFC 9110 Sections 4.2.1 and 4.2.2 require HTTP(S) authority form and a nonempty host: https:device and https:// both match generic grammar but fail those scheme requirements. A finite HTTP/HTTPS identity-syntax capability can establish ordinary cases without promising an exhaustive scheme inventory. Scheme validity supplies no claim of resource existence, DNS lookup or retrieval.
The conventional UUID input is a bare JSON string in the 8-4-4-4-12 hex-and-dash form, including upper, lower and mixed-case hex. Decode it to 16 bytes in text/network order. Esdieff adopts an opaque 128-bit value interpretation for the base UUID format, without a version or variant allowlist. Nil, Max, modern versions and reserved layouts remain representable without certifying their finer structure, interoperability or generation. This does not claim that every finer layout is defined. Any requested layout-specific meaning must retain the applicable variant requirements of RFC 9562 Section 4.1 and the corresponding version/layout requirements; unavailable needed meaning stays undetermined. UUID URNs, braces, unhyphenated text, numbers and binary arrays are other representations outside this conventional channel. Their failure here is an input-convention finding, not a universal claim that their abstract UUID is invalid. The bare-text convention and opaque interpretation follow RFC 9562 Sections 4 and 6.12.
With a common established UUID interpretation, equal decoded bytes establish value equality and differing bytes establish difference. Additional admission constraints remain separate. URI equality retains the conservative guarantee of ADR 0015: Bounded value equality in a resolved data context: compatible established identical denotations can establish equality; differing representations remain undetermined without an adopted purpose-specific comparator. No URI normalization or target-identity policy is introduced. A URI-reference denotes a reference expression; interpreting its target can require an explicit base and compatible meaning. A model namespace, source path or acquisition URI never supplies that base implicitly. Sample checking performs no network acquisition, as identification does not imply retrieval under RFC 3986 Section 1.2.2.
The scope also includes the formatted-null comparisons in ADR 0015. Complete UUID comparison therefore includes nullable values rather than requiring explicit nullable:false for model comparator capability. Known absent, true and false Full nullability are supported; unavailable or restricted Direct nullability retains its limitation. Recognizing URI or URI-reference null comparisons does not establish their still-unavailable general nonnull comparator capability. The model meaning contract describes these coverage limits.
Considered Options
Treating every generic URI success as abstract-format admission would admit known scheme-invalid identifiers. Deferring unsupported needed scheme meaning preserves that distinction without promising an exhaustive evolving scheme inventory. A URL parser that repairs input, insists on an HTTP host for every scheme, normalizes paths or accepts Unicode can change RFC 3986 inputs silently. Requiring fragment-free absolute-URI for data would confuse a distinct grammar with URI. Restricting UUID versions/variants beyond its text grammar changes opaque admission without proving generation provenance. Accepting UUID URNs as the same conventional channel is plausible but leaves format input less distinct; URNs remain URI input. Raw UUID text equality would incorrectly distinguish hex case. URI string inequality and automatic normalization would settle separate equivalence questions without a chosen purpose or base.