Version: okf 0.4.0 (npm tarball sha256 fa6a2fbd…)
What happens. A concept with the form the spec itself shows:
stale_after: 2026-10-03T00:00:00Z
is rejected by okf validate:
okf/lifecycle/stale-after-invalid — frontmatter: 'stale_after' must be an absolute YYYY-MM-DD date, got "2026-10-03T00:00:00Z" (OKF §5.5)
The same for 2026-10-03T00:00:00+00:00 and for the quoted string. Only 2026-10-03 passes.
What the spec says. OKF v0.2 §5.5, verbatim:
stale_after: 2026-09-23T00:00:00Z # content is stale on/after this instant
Optional. An absolute instant. A concept is stale when now >= stale_after.
An instant, with the example a full datetime. The validator's message cites §5.5 for a rule §5.5 does not state.
Ask. Either accept ISO 8601 datetimes (the spec's form) alongside dates, or — if date-only is the intended conformance rule — amend the spec and stop citing §5.5 as-is. Since §11 says a validator MUST accept every conformant bundle, the first reading seems the right one.
Same class as #26 (links) and #27 (frontmatter-less files): the tool is stricter than the spec it validates. Reproduced from two independent bundles.
Version: okf 0.4.0 (npm tarball sha256 fa6a2fbd…)
What happens. A concept with the form the spec itself shows:
is rejected by
okf validate:The same for
2026-10-03T00:00:00+00:00and for the quoted string. Only2026-10-03passes.What the spec says. OKF v0.2 §5.5, verbatim:
An instant, with the example a full datetime. The validator's message cites §5.5 for a rule §5.5 does not state.
Ask. Either accept ISO 8601 datetimes (the spec's form) alongside dates, or — if date-only is the intended conformance rule — amend the spec and stop citing §5.5 as-is. Since §11 says a validator MUST accept every conformant bundle, the first reading seems the right one.
Same class as #26 (links) and #27 (frontmatter-less files): the tool is stricter than the spec it validates. Reproduced from two independent bundles.