Problem description
This issue documents a CAMARA Validation warning deferred from PR #109 (Release Review r2.1, rc), per the "Document deferred validation warnings" Codeowner Action, which requires a copy of the validation summary line and the reason for deferral.
Validation summary line:
S-211 code/API_definitions/qos-booking-and-assignment.yaml 1235 warn Potentially unused component has been detected.
BOOKING_FAILURE (code/API_definitions/qos-booking-and-assignment.yaml:1235) is defined under components/examples but is not referenced from any operation's responses. Checked the createBooking operation (the only place a FAILURE-shaped BookingOutput could plausibly appear) — its 201/202 responses only reference BOOKING_SUCCESSFUL and BOOKING_PENDING. FAILURE as a status value is only reachable today via the async notification (EventBookingStatusChanged), which has its own example. So BOOKING_FAILURE is orphaned.
Reason for deferral: this is a spec-cleanup item, not release-blocking for r2.1 (rc). Recommend addressing it together with #110 and #111, since all three touch the same area of qos-booking-and-assignment.yaml / qos-booking.yaml and would otherwise mean re-opening these files three separate times.
Expected behavior
Either remove the unused BOOKING_FAILURE example, or reference it from a response where it applies (if there's a synchronous path that should document a FAILURE outcome, e.g. as an additional example on an existing error/response object).
Alternative solution
If the intent is to keep it as a general-purpose illustrative example not tied to a specific response, consider moving the reasoning into the operation description instead, since unreferenced components/examples entries aren't rendered in generated docs and will keep re-triggering S-211.
Additional context
Found while reviewing PR #109 for Commonalities 0.8.0 (r4.3) alignment issues not caught by validation, alongside #110 and #111.
Problem description
This issue documents a CAMARA Validation warning deferred from PR #109 (Release Review r2.1, rc), per the "Document deferred validation warnings" Codeowner Action, which requires a copy of the validation summary line and the reason for deferral.
Validation summary line:
BOOKING_FAILURE(code/API_definitions/qos-booking-and-assignment.yaml:1235) is defined undercomponents/examplesbut is not referenced from any operation'sresponses. Checked thecreateBookingoperation (the only place aFAILURE-shapedBookingOutputcould plausibly appear) — its201/202responses only referenceBOOKING_SUCCESSFULandBOOKING_PENDING.FAILUREas astatusvalue is only reachable today via the async notification (EventBookingStatusChanged), which has its own example. SoBOOKING_FAILUREis orphaned.Reason for deferral: this is a spec-cleanup item, not release-blocking for r2.1 (rc). Recommend addressing it together with #110 and #111, since all three touch the same area of
qos-booking-and-assignment.yaml/qos-booking.yamland would otherwise mean re-opening these files three separate times.Expected behavior
Either remove the unused
BOOKING_FAILUREexample, or reference it from a response where it applies (if there's a synchronous path that should document aFAILUREoutcome, e.g. as an additional example on an existing error/response object).Alternative solution
If the intent is to keep it as a general-purpose illustrative example not tied to a specific response, consider moving the reasoning into the operation description instead, since unreferenced
components/examplesentries aren't rendered in generated docs and will keep re-triggeringS-211.Additional context
Found while reviewing PR #109 for Commonalities 0.8.0 (r4.3) alignment issues not caught by validation, alongside #110 and #111.