Summary
A Path Item Object's undeclared keys are read off the operations map the
unmarshaller folds them into, which is what lets them be kept verbatim. A key
whose value carries a YAML anchor never lands in that map, so it reaches the
IR in no form at all — no entry, no diagnostic — while a plainly-valued key
beside it is kept and reported.
openapi: 3.1.0
info: {title: T, version: "1"}
paths:
/x:
plainBogus: {responses: {"200": {description: PLAIN}}}
bogusAnchored: &anch {responses: {"200": {description: ANCHORED}}}
get: {operationId: getX, responses: {"200": {description: ok}}}$ morphic compile p.yaml -skip-validate -o out.json
warning openapi/unknown-object-key #/paths/~1x/plainBogus: key "plainBogus" is not defined ...
$ grep -c plainBogus out.json # 1
$ grep -c PLAIN out.json # 1
$ grep -c bogusAnchored out.json # 0
$ grep -c ANCHORED out.json # 0
Two documents differing only in bogusAnchored compile to the same IR, which is
the losslessness failure (invariant 2) the census exists to end — the same class
as the one closed for the plain case.
Why it is not part of the census work
The census reads the keys the unmarshaller folded into the item's operations map
(undeclaredPathItemKeys over pi.All()). The library short-circuits an
anchored value before that fold, so there is nothing in the map to read and no
census to widen: the key is missing at the source the reader draws from.
Recovering it means reading the raw mapping node against a path item's key
vocabulary instead of reading a map the library already built — a different
mechanism from every other census site, and the same shape of work
#377 deliberately avoided.
Related
Distinct from #384 and
#395, which are about a key
merged in through << being invisible to raw-node lookups. Here the key is
written plainly and it is the value's anchor that hides it, so it is the fold
rather than the raw-node reader that loses it.
Summary
A Path Item Object's undeclared keys are read off the operations map the
unmarshaller folds them into, which is what lets them be kept verbatim. A key
whose value carries a YAML anchor never lands in that map, so it reaches the
IR in no form at all — no entry, no diagnostic — while a plainly-valued key
beside it is kept and reported.
Two documents differing only in
bogusAnchoredcompile to the same IR, which isthe losslessness failure (invariant 2) the census exists to end — the same class
as the one closed for the plain case.
Why it is not part of the census work
The census reads the keys the unmarshaller folded into the item's operations map
(
undeclaredPathItemKeysoverpi.All()). The library short-circuits ananchored value before that fold, so there is nothing in the map to read and no
census to widen: the key is missing at the source the reader draws from.
Recovering it means reading the raw mapping node against a path item's key
vocabulary instead of reading a map the library already built — a different
mechanism from every other census site, and the same shape of work
#377 deliberately avoided.
Related
Distinct from #384 and
#395, which are about a key
merged in through
<<being invisible to raw-node lookups. Here the key iswritten plainly and it is the value's anchor that hides it, so it is the fold
rather than the raw-node reader that loses it.