diff --git a/docs/includes/additional/additional20230721-17819-179l1ax b/docs/includes/additional/additional20230721-17819-179l1ax new file mode 100644 index 00000000..93415bd9 --- /dev/null +++ b/docs/includes/additional/additional20230721-17819-179l1ax @@ -0,0 +1,20 @@ +

Additional Standards

+

The Consumer Data Standards also incorporate other non-binding standards that are developed to facilitate consultation and feedback or to facilitate voluntary extension of CDR implementations.

+ +

These standards fall into three categories:

+ +
    +
  1. Candidate standards that are non-binding and stable
    2. +
  2. Draft standards that are non-binding but volatile as they are under development
    3. +
  3. Experimental standards that are transient and created to test concepts
    4. +
+

Candidate Standards

+

The Consumer Data Standards currently include the following candidate standards:

+ + +

Draft Standards

+

The Consumer Data Standards do not currently include any draft standards.

+

Experimental Standards

+

The experimental standards developed by the Data Standards Body are developed in this GitHub repository and are published here.

diff --git a/docs/includes/known-issues b/docs/includes/known-issues index eafffe12..437a322c 100644 --- a/docs/includes/known-issues +++ b/docs/includes/known-issues @@ -8,6 +8,10 @@ +Incorrect obligation date for Get Metrics v5 +The future dated obligation date has been incorrectly documented in the standards as June 13th 2024. This was a documentation error when v1.25.0 of the standards were published. According to the decision of the Data Standards Chair (Decision 288) the obligation date for the implementation of Get Metrics v5 is May 13th 2024. This will be corrected in the next release of the standards. + + Register APIs use local version of common definitions The Register APIs use a locally defined version of common schema definitions such as ResponseErrorList for error responses. These need to be updated to reference common swagger specifications inherited by the Common Swagger spec. diff --git a/docs/index.html b/docs/index.html index 7d04c95c..cf2f6941 100644 --- a/docs/index.html +++ b/docs/index.html @@ -53962,6 +53962,10 @@

Known Issues

+Incorrect obligation date for Get Metrics v5 +The future dated obligation date has been incorrectly documented in the standards as June 13th 2024. This was a documentation error when v1.25.0 of the standards were published. According to the decision of the Data Standards Chair (Decision 288) the obligation date for the implementation of Get Metrics v5 is May 13th 2024. This will be corrected in the next release of the standards. + + Register APIs use local version of common definitions The Register APIs use a locally defined version of common schema definitions such as ResponseErrorList for error responses. These need to be updated to reference common swagger specifications inherited by the Common Swagger spec. diff --git a/slate/source/includes/known-issues.md b/slate/source/includes/known-issues.md index e330d931..1dd4d68e 100644 --- a/slate/source/includes/known-issues.md +++ b/slate/source/includes/known-issues.md @@ -4,6 +4,7 @@ There are certain aspects of the standards that are actively under review. These Issue | Description :---- | :---------- +Incorrect obligation date for Get Metrics v5 | The future dated obligation date has been incorrectly documented in the standards as June 13th 2024. This was a documentation error when v1.25.0 of the standards were published. According to the decision of the Data Standards Chair (Decision 288) the obligation date for the implementation of Get Metrics v5 is **May 13th 2024**. This will be corrected in the next release of the standards. Register APIs use local version of common definitions | The Register APIs use a locally defined version of common schema definitions such as `ResponseErrorList` for error responses. These need to be updated to reference common swagger specifications inherited by the Common Swagger spec. Register APIs use different field type definitions | The Register APIs define their own field types that are not consistent with the [Common Field Types](#common-field-types) defined in the data standards. As part of porting the Register standards across to the primary data standards, the field types need to be re-aligned to use the common field type definitions. For example, `string (data-time)` should be changed to `DataTime` and `integer(int32)` should be changed to `PositiveInteger`. DCR and Register Swagger naming conventions | The DCR and Register naming conventions are not consistent with the broader data standards. Field names should be standardised to camelCase and snake_case inline with the data standards @@ -26,5 +27,3 @@ API | Updated Error Codes | New Error Codes [Get Software Products Statuses](#get-software-products-statuses) | 400:
Missing Required Header / Invalid Header / Invalid Version / Invalid Field | 404:
Invalid Industry [Get Data Recipients Statuses](#get-data-recipients-statuses) | 400:
Missing Required Header / Invalid Header / Invalid Version / Invalid Field | 404:
Invalid Industry [Get Data Recipients](#get-data-recipients) | 400:
Missing Required Header / Invalid Header / Invalid Version / Invalid Field | 404:
Invalid Industry - -