ids.ComponentSchemaName answers false for two unlike documents: one declaring no top-level component schema at that pointer, and one declaring it keyed "". Both earn no named TypeID — that part is deliberate and recorded in testdata/conformance/openapi/empty-names.yaml — but they are different facts, and a caller that reports the refusal in the first shape's words says something the document contradicts.
That already happened once. The $dynamicAnchor path reported $dynamicAnchor "m" is declared at "/components/schemas/" rather than on a component schema, when that pointer addresses exactly a component schema. #362 fixed the message and added ids.ComponentSchemaNamedEmpty so a caller can tell the two apart.
What is left
The distinction is available but opt-in. Every existing caller still reaches for ComponentSchemaName (or resolve.Scope.ComponentRef, which collapses the same two into !handled) and gets the merged answer, so the next site that reports this refusal — a hoist diagnostic, an emitter-facing message — repeats the original falsehood unless its author happens to know the extra predicate exists. #362 left a pointer to it in ComponentSchemaName's doc comment, which mitigates but does not prevent this.
The stronger shape is for the classifier itself to return the third state rather than have callers ask a second question: ComponentRef already returns (id, resolved, handled), and an entry keyed "" is a fourth condition it currently folds into !handled. Making the state explicit there would mean no caller can accidentally get the collapsed answer.
Deliberately not done in #362, which was scoped to the pointer-walk fix and would otherwise have widened a return value used across the compiler for no present caller's benefit. Filed so the choice is recorded rather than settled by whoever next touches one of these call sites.
ids.ComponentSchemaNameanswersfalsefor two unlike documents: one declaring no top-level component schema at that pointer, and one declaring it keyed"". Both earn no namedTypeID— that part is deliberate and recorded intestdata/conformance/openapi/empty-names.yaml— but they are different facts, and a caller that reports the refusal in the first shape's words says something the document contradicts.That already happened once. The
$dynamicAnchorpath reported$dynamicAnchor "m" is declared at "/components/schemas/" rather than on a component schema, when that pointer addresses exactly a component schema. #362 fixed the message and addedids.ComponentSchemaNamedEmptyso a caller can tell the two apart.What is left
The distinction is available but opt-in. Every existing caller still reaches for
ComponentSchemaName(orresolve.Scope.ComponentRef, which collapses the same two into!handled) and gets the merged answer, so the next site that reports this refusal — a hoist diagnostic, an emitter-facing message — repeats the original falsehood unless its author happens to know the extra predicate exists. #362 left a pointer to it inComponentSchemaName's doc comment, which mitigates but does not prevent this.The stronger shape is for the classifier itself to return the third state rather than have callers ask a second question:
ComponentRefalready returns(id, resolved, handled), and an entry keyed""is a fourth condition it currently folds into!handled. Making the state explicit there would mean no caller can accidentally get the collapsed answer.Deliberately not done in #362, which was scoped to the pointer-walk fix and would otherwise have widened a return value used across the compiler for no present caller's benefit. Filed so the choice is recorded rather than settled by whoever next touches one of these call sites.