You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
⚠️ Separate reduced vs full need representation for schema validation (#1652)
## Changes
- **Rename** `validate_option_fields` → `validate_fields` and
`validate_link_options` → `validate_links`
- **Add `reduce` parameter** to `get_ontology_warnings()`:
- `True` (type-specific `local`/`network` schemas): uses `reduce_need()`
— strips empty link lists and defaulted core fields. Required for
`unevaluatedProperties` (extra fields don't cause false failures) and
`required` (fields at their default are absent, so `required` enforces
explicit setting) to work correctly.
- `False` (global field/link constraint validation): uses
`NeedItem.iter_schema_items()` — returns a curated subset of fields
(core: `id`, `type`, `title`, `status`, `tags`; source: `docname`,
`is_import`, `is_external`; all extra fields; all links), filtering only
`None` values. This retains empty `[]` values for links and `tags`, so
constraints are evaluated against every need.
## Behavioral change
Previously, fields with default `[]` values (link fields like `links`,
and core fields like `tags`) were stripped before validation, silently
bypassing constraints like `minItems`, `contains`, and `minContains`.
Now with `reduce=False`, these fields are retained as `[]`, causing them
to **fail** those constraints.
This applies to both:
- **Link fields** (e.g. `links`, `implements`) — always default to `[]`
- **Core fields** with `[]` defaults (e.g. `tags`) — previously stripped
when matching the default
**Example**: A schema with `schema.minItems = 1` on `links` will now
warn for *every* need that doesn't set any links, not just those that
explicitly set links but provided too few.
## Decision needed
**Is this the correct strictness?** Two reasonable interpretations:
1. ✅ **"All needs must satisfy field/link constraints"** — the new
behavior. If you declare `minItems: 1` on a link type or `tags`, every
need must have at least one value. Users who want optional fields should
not set `minItems`.
2. ❌ **"Only needs that explicitly set a field must satisfy its
constraints"** — the old behavior. Unset/default fields are treated as
absent, not as empty arrays.
If (1) is intended, this should be noted in the changelog as a behavior
change. If (2) is preferred, the fix would be to keep `reduce_need=True`
for field/link validation, or to conditionally skip default-valued
fields when `reduce_need=False`.
### Known limitation of `reduce_need=True`
The reduction logic strips fields whose value matches the default — but
it cannot distinguish between "never set (defaulted)" and "explicitly
set to the default value." For example, if a user actively sets `:tags:`
to `[]` and the schema has `minItems: 1`, the field is stripped because
`[]` matches the default, and the violation is **silently ignored**.
This is a fundamental limitation of comparing values to defaults at
validation time, since the provenance of the value (explicit vs
implicit) is not tracked.
# we always remove null values, since we currently do not allow for `{"string", "null"}` type definitions and so null values would cause validation errors
0 commit comments