#294 nested the loose email / name / x-id / x-role keys of openapi.yml under info.contact,
matching what NodeNorm serves:
info:
contact:
email: bizon@renci.org
name: Chris Bizon
x-id: https://github.com/cbizon
x-role: responsible developer
x-id and x-role are not fields of the OpenAPI 3.0.2 Contact Object. They are presumably a
Translator convention carried as specification extensions — NodeNorm has served them this way for a
long time — but nobody has checked that against the SmartAPI validator, and #294 is the second time
this block has been wrong without anyone noticing.
Worth confirming rather than changing blind:
- Does the SmartAPI validator accept
x-id / x-role under contact, and does the registry
actually read them?
- If they are expected somewhere else (
info.x-translator, say), move them and note the convention
in CLAUDE.md.
- If they are accepted but ignored, say so in a comment in
openapi.yml so the next person doesn't
re-litigate it.
Found while fixing #294; not a regression, and the current form is at least consistent with NodeNorm.
#294 nested the loose
email/name/x-id/x-rolekeys ofopenapi.ymlunderinfo.contact,matching what NodeNorm serves:
x-idandx-roleare not fields of the OpenAPI 3.0.2 Contact Object. They are presumably aTranslator convention carried as specification extensions — NodeNorm has served them this way for a
long time — but nobody has checked that against the SmartAPI validator, and #294 is the second time
this block has been wrong without anyone noticing.
Worth confirming rather than changing blind:
x-id/x-roleundercontact, and does the registryactually read them?
info.x-translator, say), move them and note the conventionin
CLAUDE.md.openapi.ymlso the next person doesn'tre-litigate it.
Found while fixing #294; not a regression, and the current form is at least consistent with NodeNorm.