Skip to content

The editor misses a misplaced element when it is wrapped in a composite #1886

Description

@dqnykamp

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.


🤖 Generated with Claude Code

https://claude.ai/code/session_01RqRJ3QoH4UrHFR41aAkN8e

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    Priority

    None yet

    Effort

    None yet

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions