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
The editor reports an element written somewhere it does not belong, but only when it is written there directly. Wrap it in a <group> and the report disappears.
<section><series>4</series></section>
→ "Element `<series>` is not allowed inside of `<section>`."
<section><group><series>4</series></group></section>
→ nothing
Both are equally wrong, and core draws neither.
Why
Two mechanisms meet, and the gap is between them.
getSchemaViolations (lsp-tools/src/auto-completer/methods/get-schema-violations.ts) pairs each element with its immediate parent and asks isAllowedChild(parent, child). It carries a grandparent through, but only to resolve aliases — <row> inside <matrix> — not to look past a wrapper.
The content-transparent composites (<group>, <repeat>, <select>, <setup>, …) are marked allowInSchemaAnywhere, which since #1872 means they are accepted wherever their container accepts children, and since #1883 means they accept whatever their container would have. That second half is necessary — otherwise <chart><repeat><series/></repeat></chart>, which core accepts and which is the natural way to build one series per group of data, is reported as an error.
So group.children contains series, section.children contains group, and no single parent/child pair in <section><group><series/></group></section> is wrong. The wrongness is in the path, and nothing looks at the path.
Shape of a fix
Resolve a node upward through the transparent composites to the first container that actually constrains it, and check against that. <chart><repeat><series/></repeat></chart> then resolves to chart and stays clean; <section><group><series/></group></section> resolves to section and is reported.
The schema does not currently say which composites are transparent — allowInSchemaAnywhere is a build-time input to get-schema.ts, not a field on the generated elements — so this needs the generator to emit that, and the checker to walk it.
Related, and probably the same fix
<option> / <case> do not accept a narrowed child.<chart><select><option><series/></option></select></chart> is reported today. <option> is not itself transparent (it takes named children), so the widening does not reach it, but a <select> of <option>s is how an author picks between series. The same "resolve to the container that constrains" walk would cover it. Pre-existing: identical for <shortDescription> on main.
Decide how schema-derived diagnostics should relate to core's #1555 — how schema-derived diagnostics should relate to core's. This is the over-reporting direction of that issue, and its "teach the schema about composites" option; the under-reporting direction is what this issue is about.
Not urgent
Nothing here is a regression. Before <series> existed there was nothing narrowed to hide in a wrapper, and the wrapped case has never been reported. The direct case is newly caught, which is a strict improvement — this issue is about the half that is still missing.
Pinned by a test in lsp-tools/test/doenet-auto-schema-check.test.ts
("Does not see a chart-only child hidden inside a wrapper") so the gap has a
shape and a future fix has something to flip.
The editor reports an element written somewhere it does not belong, but only when it is written there directly. Wrap it in a
<group>and the report disappears.Both are equally wrong, and core draws neither.
Why
Two mechanisms meet, and the gap is between them.
getSchemaViolations(lsp-tools/src/auto-completer/methods/get-schema-violations.ts) pairs each element with its immediate parent and asksisAllowedChild(parent, child). It carries a grandparent through, but only to resolve aliases —<row>inside<matrix>— not to look past a wrapper.The content-transparent composites (
<group>,<repeat>,<select>,<setup>, …) are markedallowInSchemaAnywhere, which since #1872 means they are accepted wherever their container accepts children, and since #1883 means they accept whatever their container would have. That second half is necessary — otherwise<chart><repeat><series/></repeat></chart>, which core accepts and which is the natural way to build one series per group of data, is reported as an error.So
group.childrencontainsseries,section.childrencontainsgroup, and no single parent/child pair in<section><group><series/></group></section>is wrong. The wrongness is in the path, and nothing looks at the path.Shape of a fix
Resolve a node upward through the transparent composites to the first container that actually constrains it, and check against that.
<chart><repeat><series/></repeat></chart>then resolves tochartand stays clean;<section><group><series/></group></section>resolves tosectionand is reported.The schema does not currently say which composites are transparent —
allowInSchemaAnywhereis a build-time input toget-schema.ts, not a field on the generated elements — so this needs the generator to emit that, and the checker to walk it.Related, and probably the same fix
<option>/<case>do not accept a narrowed child.<chart><select><option><series/></option></select></chart>is reported today.<option>is not itself transparent (it takes named children), so the widening does not reach it, but a<select>of<option>s is how an author picks between series. The same "resolve to the container that constrains" walk would cover it. Pre-existing: identical for<shortDescription>onmain.Not urgent
Nothing here is a regression. Before
<series>existed there was nothing narrowed to hide in a wrapper, and the wrapped case has never been reported. The direct case is newly caught, which is a strict improvement — this issue is about the half that is still missing.Pinned by a test in
lsp-tools/test/doenet-auto-schema-check.test.ts("Does not see a chart-only child hidden inside a wrapper") so the gap has a
shape and a future fix has something to flip.
🤖 Generated with Claude Code
https://claude.ai/code/session_01RqRJ3QoH4UrHFR41aAkN8e