V0.39.0
Name:v0.39.0Status:active

v0.39.0 — Declarations, part two

v0.38.0 deleted what was provably inert and made two declarations reach the reader and the runtime. This milestone continues on the same line, one level up: the remaining places where a rune's behaviour is written as code but is really data, plus the one place where the two schema resolvers' disagreement already publishes wrong structured data.

These are also the self-contained foundations of the composed-runes work (SPEC-145, SPEC-153, SPEC-156). Each one is valuable on its own and does not depend on composition landing. Composition itself is deliberately not in this milestone.

Milestone burndown: 1 open work item remaining; peak 2, started Oct 7012Oct 7Oct 11
Open work items Ideal burndown
Progress 1/1 work items
Related 23
History 1
  1. 5191d3e
    Created (active)by bjornolofandersson

Work Items

Done 1
WORK-609 main
Stop findChildren retyping author-nested runes of a colliding name
SPEC-146 Problem 1, the present-tense half. findChildren (packages/runes/src/lib/schema-table.ts) matches a schema children key against data-rune as well as data-name / data-field, descends the whole subtree and applies every match. So playlist's children: { track } retypes an author's own {% track %} nested in an unrelated container as one of the playlist's tracks, and because the child row is applied with the author's node as root, the row's own properties resolve inside it. The SPEC records the result in the JSON-LD graph, not only in RDFa: an unrelated recording published as a track.The colliding rows are a closed set: playlist's musicRow/spokenRow and breadcrumb's breadcrumb-item carry their own properties and reach the graph; recipe/howto (step), pricing (tier), timeline and accordion carry text/generated only and mis-stamp RDFa.
high moderate
9/9 criteria