Review property requirements in Get Metrics schemas

[nils-work]

Description

Most of the properties in the Get Metrics response schema are marked as conditional but there are no conditions specified.
I expect many of these are intended to be mandatory.

Most of the sub-object properties are also conditional but that may relate to the period parameter of the endpoint specifying whether the CURRENT, HISTORIC (previous) or ALL values are being requested.

Properties in InvocationMetrics and AverageResponseMetrics are all conditional but the top-level objects in those schemas may be mandatory.

The RejectionMetrics properties are all optional which is different to the definitions for the other schemas which may also have only '0' values to report, if that is the reason behind their optionality (ErrorMetrics for example.)

Area Affected

ResponseMetricsList schema and sub-schemas.

Change Proposed

Clarify the requirements of the properties and update the schema documentation.

[CDR-API-Stream]

Hi @nils-work you are correct, and this issue is considered to be a documentation defect. An early draft of the data standards used to have a query parameter allowing specific metrics to be requested which was later removed however the conditionality at the object-level for the Metrics API response was not updated. This will be corrected in the current iteration.

The expectation has been that the DH will provide the full list of metrics when requested.

The field-level properties of the primary objects are conditional because they are based on the period query parameter and remain conditional.

[CDR-API-Stream]

This fix has been staged for review here: https://github.com/ConsumerDataStandardsAustralia/standards-staging/tree/maintenance/345

[nils-work]

Hi @CDR-API-Stream

The last line of this issue relates to the fields highlighted below in the RejectionMetricsV2 schema all being optional, which is different to the other object requirements.
It seems they should be a combination of mandatory and conditional -

[CDR-API-Stream]

Thank you @nils-work this is a documentation defect and will be corrected in the staged changes on standards-staging branch maintenance/345

[CDR-API-Stream]

These changes have been staged and they are available for review here: ConsumerDataStandardsAustralia/standards-staging@release/1.8.0...maintenance/345

[nils-work]

Hi @CDR-API-Stream
Thank you for the updates, but it looks like there is a typo here for those last changes.
It should just be required

[CDR-API-Stream]

Thanks Nils. This was building fine as-is however it has been corrected.

[CDR-API-Stream]

The outcome of this issue has been approved by the Data Standards Chair for inclusion in v1.9.0. A change to the data standards was recommended.

This issue will be closed accordingly.