Addition of known issue entry for Get Metrics v5 (#319)

Addition of known issue entry for Get Metrics v5

docs/includes/additional/additional20230721-17819-179l1ax

@@ -0,0 +1,20 @@
+<h1 id='additional-standards'>Additional Standards</h1>
+<p>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.</p>
+
+<p>These standards fall into three categories:</p>
+
+<ol>
+<li><code>Candidate</code> standards that are non-binding and stable</li>
+<li><code>Draft</code> standards that are non-binding but volatile as they are under development</li>
+<li><code>Experimental</code> standards that are transient and created to test concepts</li>
+</ol>
+<h2 id='candidate-standards'>Candidate Standards</h2>
+<p>The Consumer Data Standards currently include the following candidate standards:</p>
+
+<ul>
+<li><a href="./includes/additional/candidates/telco.html">Candidate standards for the Telecommunications sector</a></li>
+</ul>
+<h2 id='draft-standards'>Draft Standards</h2>
+<p>The Consumer Data Standards do not currently include any draft standards.</p>
+<h2 id='experimental-standards'>Experimental Standards</h2>
+<p>The experimental standards developed by the Data Standards Body are developed in this <a href="https://github.com/ConsumerDataStandardsAustralia/standards-experimental">GitHub repository</a> and are <a href="https://consumerdatastandardsaustralia.github.io/standards-experimental/">published here</a>.</p>

docs/includes/known-issues

@@ -8,6 +8,10 @@
 </tr>
 </thead><tbody>
 <tr>
+<td style="text-align: left">Incorrect obligation date for Get Metrics v5</td>
+<td style="text-align: left">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 <strong>May 13th 2024</strong>.  This will be corrected in the next release of the standards.</td>
+</tr>
+<tr>
 <td style="text-align: left">Register APIs use local version of common definitions</td>
 <td style="text-align: left">The Register APIs use a locally defined version of common schema definitions such as <code>ResponseErrorList</code> for error responses. These need to be updated to reference common swagger specifications inherited by the Common Swagger spec.</td>
 </tr>

docs/index.html

@@ -53962,6 +53962,10 @@ <h1 id='known-issues'>Known Issues</h1>
 </tr>
 </thead><tbody>
 <tr>
+<td style="text-align: left">Incorrect obligation date for Get Metrics v5</td>
+<td style="text-align: left">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 <strong>May 13th 2024</strong>.  This will be corrected in the next release of the standards.</td>
+</tr>
+<tr>
 <td style="text-align: left">Register APIs use local version of common definitions</td>
 <td style="text-align: left">The Register APIs use a locally defined version of common schema definitions such as <code>ResponseErrorList</code> for error responses. These need to be updated to reference common swagger specifications inherited by the Common Swagger spec.</td>
 </tr>

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: <br />Missing Required Header / Invalid Header / Invalid Version / Invalid Field | 404: <br />Invalid Industry
 [Get Data Recipients Statuses](#get-data-recipients-statuses) | 400: <br />Missing Required Header / Invalid Header / Invalid Version / Invalid Field | 404: <br />Invalid Industry
 [Get Data Recipients](#get-data-recipients) | 400: <br />Missing Required Header / Invalid Header / Invalid Version / Invalid Field | 404: <br />Invalid Industry
-
-