info-tech-canon/demand/AttributeValueTypes.md
tegwick d453e17952
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
Canon 0.6.0 freeze: ITC-CAP draft, AVT catalog, joinable review
Finish ITC-WP-0013 (AttributeValueType under ITC-DATA) and ITC-WP-0014
T02/T03/T05/T06/T07. Capability contract schemas, live-catalog review
CLI, landscape/kernel-map pointers. Sit on this version.
2026-08-15 19:42:30 +02:00

2.3 KiB

Demand: Attribute Value Type Catalog

Status: accepted (canon 0.6.0)
Date: 2026-07-30
Source: citation-evidence Capture UX (consumer)
Related consumer draft: citation-evidence/wiki/AttributeValueTypes-proposal.md
Workplan: ITC-WP-0013
Catalog: infospace/models/data/attribute-value-types.yaml
Alignment: infospace/models/data/attribute-value-types-alignment.md


Demand signal

Consumer citation-evidence needs a closed, versioned catalog of attribute value types for evidence-backed structured capture (key / type / value), including:

  • time, datetime
  • amount (quantity + currency)
  • one-of (single selection from a code list)
  • some-of (multi selection from a code list)

plus existing scalars text, long text, date.

The consumer must not invent a permanent private type system if InfoTechCanon is the semantic reference layer for info-tech domains.


Gap vs current canon

InfoTechCanonDataModel already defines:

  • Attribute, Field, DataElement, Representation, DataType, CodeList, Constraint

But:

  • DataType is only a one-line stub,
  • Representation lists open examples without a closed catalog,
  • there is no machine-readable AttributeValueType registry for application forms / capture UIs.

This demand is for a canonical collection of value types (and encoding rules), not for a new domain entity competing with Attribute/Field.


Proposed placement

Preferred: extension or section under ITC-DATA (Data Model):

  • concept: AttributeValueType (or closed Representation profile for capture/forms)
  • artifact: markdown standard + YAML catalog under infospace/
  • relationships: AttributeValueType → CodeList (for one-of/some-of), → Constraint

Avoid: scattering type ids only inside citation-evidence.


Success criteria

  1. Closed list of type ids with definitions and wire encodings.
  2. Clear mapping to Representation / CodeList / Constraint.
  3. Consumer citation-evidence can depend on the catalog (copy or generated constants) without forking names.
  4. Processed via Purpose/Demand if required by ITC-WP-0006 before kernel edit.

Non-goals

  • Full statistical data type system.
  • UI widget standards (consumer concern).
  • Vendor form-builder schemas (SurveyJS, etc.) as canon.