Validation warnings: align CloudEvents definition with Commonalities guidelines

[albertoramosmonagas]

Problem description

The current validation of the Predictive Connectivity Data API passes with warnings that should be addressed or formally tracked before release.

The current validation reports the following warnings:

• [P-015] CloudEvent type format is wrong
  • The subscription API does not define a named EventType schema. Instead, the CloudEvent type value is defined inline.
  • Current recommendation from Commonalities is to define a dedicated event type schema (for example ApiEventType) using allOf, following the implicit-events template.
• [S-035] Notification must use application/cloudevents+json
  • The notification callback currently defines application/json instead of the required application/cloudevents+json.

The validation also reports several S-313 hints for free-form string fields. These are considered acceptable implementation-dependent fields and do not require changes.

Expected behavior

Update the API specification to align with the current CAMARA/Commonalities recommendations by:

• Defining a dedicated EventType schema for CloudEvents instead of inlining the enum.
• Updating the notification callback media type to application/cloudevents+json.
• Keeping the existing free-form string fields unchanged, documenting that the reported S-313 hints are expected and do not require action.

This should remove the current validation warnings while maintaining compatibility with the Commonalities CloudEvents guidance.

Alternative solution

If these changes cannot be completed before the current release, this issue can serve as the required documentation for the deferred validation warnings, as requested by the validation workflow for release branches.

Additional context

Validation summary:

• P-015 – CloudEvent type format is wrong
• S-035 – Notification callback must use application/cloudevents+json
• S-313 hints are informational and correspond to implementation-dependent free-form string fields, therefore no action is planned for them.

Validation workflow: https://github.com/camaraproject/PredictiveConnectivityData/actions/runs/30337548978

[albertoramosmonagas]

Only for clarification, this issue has been created following the Release Management revision rules, but I think we should distinguish between an event notification and an asynchronous response. In this API, the callback delivers the final result of a previously accepted request exactly once; it is not reporting an event that may occur independently or repeatedly.

This distinction is now being clarified in Commonalities PR camaraproject/Commonalities#575, based on Issue #533. The proposed guidance explicitly states that asynchronous responses do not need to use the CAMARA CloudEvents model and should instead reuse the equivalent synchronous response model.

Therefore, the current linter warnings do not necessarily indicate that the API design is incorrect; the validation rules may not yet account for this distinction. The existing issue already documents the relevant P-015 and S-035 warnings for release purposes. Under the release-management guidelines, documented warnings and applicable hints are not blockers for the RC.