Schema-explained prefix of an untrusted document path.
Strict JSON decoding and schema validation report a fault as a raw path into the document: object keys as binaries, array indices as non-negative integers. Those segments are caller-authored, so a diagnostic must not echo them back unchecked.
explained_prefix/2 walks such a path through the schema that rejected the
document and keeps only the leading segments the schema accounts for, tagged
as PtcRunner.Kernel.CommandPath.segment/0. Traversal covers properties,
items, and oneOf, and stops at the first segment the schema cannot
explain, so every returned segment is one the schema authorizes.
Keywords that admit caller-chosen names — additionalProperties above all —
never contribute the caller's own key. Where the map's propertyNames proves
no admissible member could render as the elision placeholder
PtcRunner.Kernel.CommandPath owns, the key is replaced by that placeholder
and the walk continues into the closed schema beneath it; where it cannot,
the walk stops at the map as before. A host diagnostic under install therefore reaches
/install/*/ceilings/timeout_ms while naming no installation, and one under
install/*/tools — whose members are upstream tool names, and which admits
* itself — still stops, because an ambiguous pointer is worse than a short
one.
A oneOf descends into the first branch that explains the current segment.
A branch selected with knowledge of the whole remaining path could sometimes
explain more, so the result is the shortest safe prefix rather than the
longest possible one — truncating early loses diagnostic precision, never
authority. PtcRunner.Kernel.CommandPath authorizes an already-tagged path
and resolves oneOf against the whole remainder instead.
Summary
Functions
Returns the leading segments of path that schema structurally explains.
Functions
@spec explained_prefix([binary() | non_neg_integer()], map()) :: [ PtcRunner.Kernel.CommandPath.segment() ]
Returns the leading segments of path that schema structurally explains.