Propose AttributeValueType catalog research and CE-WP-0012.
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

Document gap vs InfoTechCanon Data Model stubs; plan consumer types
time/datetime/amount/one-of/some-of aligned with a future ITC catalog.
This commit is contained in:
tegwick 2026-07-30 20:58:25 +02:00
parent 154e48cdd2
commit d4327b6be6
3 changed files with 388 additions and 2 deletions

View file

@ -33,11 +33,13 @@ publish tasks wait on ADR-0002 resolution.
|----------|-------|--------|
| `CE-WP-0010` | Annotate & Attributes UX — labels, filters, layout, evidence connectors | finished |
| `CE-WP-0011` | Attributes guide n:m lines, title migration, Add attribute placement | finished |
| `CE-WP-0012` | Attribute value types — time, datetime, amount, one-of, some-of | proposed |
User-facing polish after manual document review: rename Review→Annotate, keep
Evidence column in Capture with Attributes on the right, list filters, and
card→citation connector lines. CE-WP-0011 adds n:m attribute↔evidence guides,
legacy title migration, and Add attribute below the list.
card→citation connector lines. CE-WP-0011 adds n:m attribute↔evidence guides.
CE-WP-0012 extends attribute types; canon ownership tracked as ITC-WP-0013
(see `wiki/AttributeValueTypes-proposal.md`).
## Order

View file

@ -0,0 +1,200 @@
# Proposal: Attribute Value Type Canon (consumer + InfoTechCanon)
**Status:** research draft (2026-07-30)
**Consumers:** citation-evidence Capture attributes
**Producer candidate:** info-tech-canon (Data Model extension)
**Related:** CE-WP-0012, ITC-WP-0013 (proposed)
---
## 1. Problem
citation-evidence Capture attributes currently support only:
| Type id | UI | Value shape |
|---------|-----|-------------|
| `text` | single-line input | string |
| `textarea` | multi-line | string |
| `date` | HTML date | ISO calendar date string |
Real evidence-backed capture (legal, finance, admin) needs richer types:
**time**, **datetime**, **amount** (money), **one-of** (single choice),
**some-of** (multi choice), without inventing an ad-hoc enum only for this app.
---
## 2. What InfoTechCanon already has
### 2.1 Present (seed)
`InfoTechCanonDataModel` (ITC-DATA) already names structure/semantic concepts:
| Concept | Role |
|---------|------|
| **Field** | Named structural component of a schema/record |
| **Attribute** | Property of a data object / conceptual entity (semantic) |
| **DataElement** | Unit of data with meaning + representation (ISO 11179aligned) |
| **Representation** | How a data element is represented (*examples*: string, integer, decimal, boolean, date, timestamp, code, identifier, URI) |
| **DataType** | “Technical or logical type of a field or data element” — **stub only** |
| **CodeList** | Controlled permitted values (country, currency, status…) |
| **Constraint** | required, unique, min/max, regex, enum, format, cardinality |
### 2.2 Missing
There is **no closed, versioned catalog** of:
- application-facing **value types** (what control to render, how to validate),
- **storage encoding** conventions (JSON/string wire form),
- **cardinality** for choices (`one-of` vs `some-of`),
- **quantity + unit/currency** for amounts.
So the users intuition is correct: Attribute/Field exist as *entity kinds*,
but not as a **canonical collection of attribute value types**.
---
## 3. Recommended split of concerns
```text
InfoTechCanon (producer)
└── AttributeValueType catalog (closed enum + encoding rules)
owns: type id, meaning, wire encoding, constraints hooks
does NOT own: React widgets, PDF viewer, evidence links
citation-evidence (consumer)
└── Capture Attribute schema + UI adapters
owns: FormFieldSchema, editors, filters, evidence links
maps: AttributeValueType → widget + validation
```
citation-evidence should **not** be the long-term owner of the type list;
it may ship a consumer profile that imports the catalog once ITC lands.
---
## 4. Proposed AttributeValueType catalog (v0)
Ids are stable machine tokens (kebab-case). Display labels are UI concerns.
### 4.1 Scalars (single value)
| id | Label | Wire value (MVP) | Notes |
|----|-------|------------------|--------|
| `text` | Text | string | short free text |
| `text-long` | Long text | string | replaces UI-only name `textarea` |
| `boolean` | Yes/No | `"true"` \| `"false"` or JSON bool (TBD) | not requested yet; keep reserved |
| `integer` | Integer | decimal digits string | reserved |
| `number` | Number | decimal string | reserved |
| `date` | Date | `YYYY-MM-DD` | existing |
| `time` | Time | `HH:MM` or `HH:MM:SS` | **requested** |
| `datetime` | Date & time | ISO-8601 local or offset | **requested** |
| `amount` | Amount | structured JSON or `"number unit"` | **requested** — see §4.3 |
| `uri` | URI | string URI | reserved |
| `identifier` | Identifier | string | reserved |
### 4.2 Choice types (CodeList-backed)
| id | Label | Cardinality | Wire value (MVP) |
|----|-------|-------------|------------------|
| `one-of` | One of | 1 | selected option id (string) |
| `some-of` | Some of | 0..n | JSON array of option ids |
Both require an **options** (CodeList) attachment on the attribute definition:
```yaml
type: one-of
options:
- { id: "cash", label: "Cash" }
- { id: "transfer", label: "Bank transfer" }
```
This maps cleanly to ITC **CodeList** + **Constraint.enum** / cardinality.
### 4.3 Amount
Prefer a structured wire form so currency is not lost:
```json
{ "value": "1500.00", "currency": "EUR" }
```
MVP UI: number input + currency select (ISO 4217 subset or free code).
Alternative interim: single string `"1500.00 EUR"` with a parser — weaker.
Maps to ITC Representation `decimal` + CodeList `currency` + optional unit.
### 4.4 Aliases / compatibility
| Legacy CE id | Canonical id |
|--------------|--------------|
| `textarea` | `text-long` |
Keep accepting `textarea` on load; normalize on write.
---
## 5. Orthogonality rules (avoid bloating the enum)
Do **not** add separate types for:
- “required” → Constraint
- “email” / “phone” → `text` + format constraint (or later `text` profiles)
- “percentage” → `number` + unit/scale constraint
- “file attachment” → different entity (evidence/document), not attribute value type
Choice lists are **not** separate types per domain list; they are `one-of`/`some-of` + CodeList.
---
## 6. Alignment with external practice (quick)
| Source | Overlap |
|--------|---------|
| HTML input types | date, time, datetime-local, number, text |
| JSON Schema | string/number/boolean/array + enum + format |
| ISO 11179 | Data element concept vs representation |
| FHIR / XBRL | rich quantity + codeable concepts (too heavy for MVP) |
We stay closer to **HTML + CodeList** than to FHIR for Capture MVP.
---
## 7. Implementation phasing
### Phase A — Canon (info-tech-canon)
1. Demand signal (this documents substance).
2. Seed standard: `AttributeValueType` catalog under Data Model or sibling standard.
3. Machine-readable list: YAML + schema in `infospace/`.
4. Mapping notes: Representation examples ↔ AttributeValueType.
### Phase B — Consumer (citation-evidence)
1. Extend `FormFieldSchema` / `FieldType` to the closed catalog.
2. Widgets: time, datetime-local, amount (value+currency), radio/select (one-of), checkbox group (some-of).
3. Option editor when type is one-of/some-of.
4. Persist options in capture-state; migrate `textarea``text-long`.
5. Filters match option labels as well as values.
### Phase C — Later
- Shared package `@infotech/attribute-value-types` or canon-generated TS constants.
- Server-side validation; multi-currency policy; localization of labels.
---
## 8. Decision asks (for Bernd)
1. **Owner:** confirm InfoTechCanon Data Model as home for the catalog (vs app-local only).
2. **Amount encoding:** structured JSON vs plain string for MVP?
3. **textarea rename:** keep display “Text area”, wire id `text-long` vs keep `textarea` forever?
4. **boolean / integer / number:** reserve now, implement later?
5. **one-of UI default:** native `<select>` vs radio list?
---
## 9. References
- `info-tech-canon/seeds/InfoTechCanonDataModel_RC1_seed.md` §§11.1011.17
- `citation-evidence` / `evidence-binder` `FormFieldSchema` (`text` \| `textarea` \| `date`)
- CE-WP-0003 form binding; CE-WP-0010 Attributes vocabulary

View file

@ -0,0 +1,184 @@
---
id: CE-WP-0012
type: workplan
title: "Attribute value types — time, datetime, amount, one-of, some-of"
domain: infotech
repo: citation-evidence
repo_id: a677c189-b4e2-4f2a-9e48-faa482c277e6
topic_slug: citation_evidence_mvp
topic_id: cee7bedf-2b48-46ef-8601-006474f2ad7a
status: proposed
owner: codex
created: "2026-07-30"
updated: "2026-07-30"
depends_on_workplan: CE-WP-0011
planning_order: 12
planning_priority: high
spec_refs:
- wiki/AttributeValueTypes-proposal.md
- workplans/CE-WP-0010-annotate-attributes-ux.md
- ../info-tech-canon/seeds/InfoTechCanonDataModel_RC1_seed.md
---
# CE-WP-0012 — Attribute Value Types
Extend Capture attributes beyond `text` / `textarea` / `date` with the types
needed for real evidence work, aligned with a **canonical AttributeValueType
catalog** (proposed under InfoTechCanon; interim consumer profile in
`wiki/AttributeValueTypes-proposal.md`).
## Research summary (locked finding)
InfoTechCanon **Data Model** already defines **Attribute**, **Field**,
**DataType**, **Representation**, and **CodeList**, but **DataType is a stub**
and there is **no closed catalog** of application value types. Representation
only lists open examples (`string`, `date`, `timestamp`, `code`, …).
Therefore: establish the catalog in InfoTechCanon (ITC-WP-0013), implement UI
and persistence here as a **consumer**.
## User-requested types (MVP slice)
| Type | Purpose |
|------|---------|
| `time` | Clock time without date |
| `datetime` | Date + time |
| `amount` | Quantity with currency (or unit) |
| `one-of` | Single choice from options |
| `some-of` | Multi choice from options |
Keep existing: `text`, `textarea` (alias `text-long`), `date`.
## Goals
1. Schema + UI support for the MVP types above.
2. Option lists for `one-of` / `some-of` editable in Capture.
3. Wire encoding documented and round-tripped in capture-state + tests.
4. No fork of type ids: prefer names from `wiki/AttributeValueTypes-proposal.md`
once ITC catalog exists; until then use the proposal as interim canon.
## Non-goals
- Full ISO 11179 registry product.
- Arbitrary JSON Schema forms.
- Server-side validation service.
- Publishing a shared npm package in this workplan (may follow).
## Dependency order
```
T01 (decide wire encodings + finalize interim catalog in wiki)
└─ T02 (extend FormFieldSchema + FieldDefinitionForm types)
└─ T03 (widgets: time, datetime, amount)
└─ T04 (widgets: one-of, some-of + options editor)
└─ T05 (persist options; migrate legacy textarea if needed)
└─ T06 (tests + demo schema examples)
```
Parallel: **ITC-WP-0013** formalizes the catalog in info-tech-canon; CE may
ship T01T06 against the wiki proposal and remap ids if ITC renames.
---
## T01 — Finalize interim catalog + encodings
```task
id: CE-WP-0012-T01
status: todo
priority: high
```
Resolve decision asks in `wiki/AttributeValueTypes-proposal.md` §8 with
operator; freeze MVP wire forms for amount / one-of / some-of.
**Acceptance:** proposal §4 marked “accepted for CE MVP” (or amended).
---
## T02 — Schema extension
```task
id: CE-WP-0012-T02
status: todo
priority: high
depends_on: [T01]
```
Extend `FormFieldSchema` / `FieldType` in evidence-binder:
- add `time`, `datetime`, `amount`, `one-of`, `some-of`
- optional `options?: { id, label }[]` for choice types
- optional amount metadata (default currency) if needed
**Acceptance:** typecheck green; FieldDefinitionForm lists new types.
---
## T03 — Scalar widgets (time, datetime, amount)
```task
id: CE-WP-0012-T03
status: todo
priority: high
depends_on: [T02]
```
Render HTML `time`, `datetime-local` (or split date+time), and amount UI.
Values persist as strings (or structured JSON for amount per T01).
**Acceptance:** add/edit/value round-trip for each type in DOM tests.
---
## T04 — Choice widgets (one-of, some-of)
```task
id: CE-WP-0012-T04
status: todo
priority: high
depends_on: [T02]
```
- `one-of`: select or radio
- `some-of`: checkbox group
- options editor when defining the attribute
**Acceptance:** create attribute with options, select values, persist.
---
## T05 — Capture-state compatibility
```task
id: CE-WP-0012-T05
status: todo
priority: medium
depends_on: [T03, T04]
```
- load/save options in capture-state
- accept legacy sessions without options
- document amount/some-of JSON in capture-persistence comments
---
## T06 — Tests + demo attributes
```task
id: CE-WP-0012-T06
status: todo
priority: medium
depends_on: [T05]
```
- unit/DOM coverage for new types
- optional demo schema fields exercising amount + one-of
- `pnpm test` green
---
## Out of scope / follow-ups
- Align TypeScript const enum with published ITC YAML.
- Evidence extraction helpers that suggest amount/date from PDF quotes.
- Validation constraints (min/max, regex) as first-class UI.