New ErrorInfo schema alters the expected properties order

[jlurien]

Problem description
CAMARA_common.yaml in r3.3 updated ErrorInfo schema with enhanced descriptions, but changing the order of the properties that appeared in previous versions, and is used in all guidelines and specifications, which was status -> code -> message

Expected behavior
The same order should be kept. Even if both schemas are equivalent and examples are still compliant with the new schema, tools (spec viewers, code generators, etc) usually respect the schema order.

Alternative solution
If this is not patched before M4 due to time constraints, WGs should ignore the new order and preserve the original one, updating only the enhanced descriptions.

[PedroDiez]

Background Info:

Have been aligning this with @jlurien and indeed we have the problem within CAMARA_common.yaml since time ago as the "order" indicated is not the suitable one:

So when PR #506 was done, that problem was also expanded to other documents (as CAMARA_common.yaml was taken as the reference)

I think that for MetaRelease Fall25 we can be flexible with any order as that does not imply any functional constrain. Anyway the APIs that in advance align with the "order"

• status
• code
• message

are more than welcome.

FYI @jlurien, @Kevsy, @eric-murray, @bigludo7, @patrice-conil, @rartych, @tanjadegroot, @hdamker

Within the related PR (I will generate next week) We will be aligning considering the one indicated in API Design guide: https://github.com/camaraproject/Commonalities/blob/main/documentation/CAMARA-API-Design-Guide.md#3-error-responses

[hdamker]

I'm in favor to create a patch release of Commonalities r3.4 as soon as possible to resolve the discrepancy between API Design Guide and the CAMARA_common.yaml and have a stronger argument to stop the unnecessary changes of the order within established APIs partially done last minute (see above mentioning).

We need to discuss in ReleaseManagement how to handle the situation. Updating all references to Commonalities again to 3.4 will not work. But the preferred order should be

• status
• code
• message

as shown in API Design Guide. If an API had this order already in a previous release it SHOULD not change it.