fix: minor corrections from automatic validation

[DLondonoD]

What type of PR is this?

Add one of the following kinds:

• correction

What this PR does / why we need it:

Automatic validation from PR 24 resulted in some warnings (See here).

This PR aims to fix them

Which issue(s) this PR fixes:

Special notes for reviewers:

Changelog input

 release-note

Additional documentation

This section can be blank.

docs

[seralogar]

Two observations on r4.2 alignment that may be worth addressing (in this PR or a follow-up):

1. maxLength: 32 on date-time fields

accessTokenExpiresUtc (line 1121) and subscriptionExpireTime (line 1207) use maxLength: 32, but the r4.2 CAMARA_common.yaml DateTime schema defines maxLength: 64:

# code/common/CAMARA_common.yaml
DateTime:
  type: string
  format: date-time
  maxLength: 64

Should these fields use maxLength: 64 to stay consistent — or better yet, $ref: "../common/CAMARA_common.yaml#/components/schemas/DateTime"?

2. Error responses and shared schemas still defined inline

ErrorInfo, XCorrelator, and all error responses (400–503) are defined locally in the spec. The r4.2 CAMARA_common.yaml provides Generic400–Generic504 responses and these shared schemas specifically so APIs can consume them via $ref rather than duplicating them.

Would it make sense to replace the local definitions with $refs to ../common/CAMARA_common.yaml? For example:

responses:
  "400":
    $ref: "../common/CAMARA_common.yaml#/components/responses/Generic400"

---

I understand this PR's scope is "minor corrections from automatic validation," so these might be better suited for a separate PR. Just flagging the inconsistency since the spec already declares x-camara-commonalities: 0.8.0-rc.2.

[Kevsy]

^ @seralogar good catches, but yes, it may be better to apply in another PR.

Meanwhile there appear to still be some missing descriptions and string constraints in the validation report for this PR - @DLondonoD is the intention to fix those here?

[diegogonmar]

@Kevsy, I think your intention was to mention @DLondonoD , a different Diego :-)

[Kevsy]

@Kevsy, I think your intention was to mention @DLondonoD , a different Diego :-)

Ooops thanks! Now corrected :)

[DLondonoD]

Hi @seralogar @Kevsy,

Thanks for your review!

@seralogar I agree that the mentioned inconsistencies should be addressed in a new PR.

@Kevsy Most of the remaining notices are related to the absence of defined format, pattern or enum contraints for certain String fields. While commonalities recommends specifying these contraints for Strings whenever possible, in these cases there is not clear or consistent pattern (e.g. names, tokens). Therefore, I believe it is unnecessary to define a format or pattern for them.

On the other hand, there are still two warnings in the callbacks. I suspect these are due to a validation error, since attempting to fix the warning actually introduces an error S-209.

Update

I have created an issue in the tooling repo camaraproject/tooling#296
@hdamker, @Kevsy could you please help me to take a look? Thanks!

[JoseMConde]

LGTM

[hdamker]

I have created an issue in the tooling repo camaraproject/tooling#296
@hdamker, @Kevsy could you please help me to take a look? Thanks!

@DLondonoD The issue is fixed; the warnings are gone (see re-run of validation: https://github.com/camaraproject/EdgeApplicationManagement/actions/runs/26240613361?pr=27).