Maintenance Iteration 20 Holistic Feedback

[CDR-API-Stream]

This change request has been created to simplify the raising of minor changes, such as text corrections or description clarifications, that are not really material to the standards but do have a real impact on readability and clarity.

Please raise any such suggestions that you would like included in Maintenance Iteration 20 on this issue and the DSB will review them. If a suggestion is a material change a dedicated CR will be raised.

[nils-work]

In the section Data Recipients calling Data Holders, the first bullet point appears to be redundant and could be removed - the second point seems to state the same requirement more clearly (change highlighted here).

There is a typo in the first sentence of the third point. Make the following change:

- authorisation_code
+ authorization_code

[nils-work]

Documentation updates:

• #410 - Clarify RateString description and examples
• #411 - Fix typos

[nils-work]

In the Security Profile section > Data Recipients calling Data Holders, the requirements in the first two bullet points appear to be repeated. The highlighted text in the statements is identical:

The proposal is to remove the first bullet point:

• The client ID represents the ID issued to the Data Recipient Software Product by the Data Holder upon successful dynamic client registration.

[nils-work]

There appears to be a copy/paste error in the description of the tariffUType field in the EnergyPlanSolarFeedInTariffV3 schema:

- The type of the payer
+ Reference to the applicable tariff structure.

[nils-work]

The "Reference to the applicable [type] structure." convention could be applied to all ...UType field descriptions for consistency and clarity of interpretation.

The following sample shows the current variation across schemas:

• The type of recurrence used to define the schedule.
• The type of structure to present account specific fields.
• Indicator of the type of transaction object present in this record
• The type of address object present
• The type of object present in this response (from EnergyPaymentSchedule)
• Type of object included that describes the payee in detail.
• The type of customer object that is present
• Type of account object included.

[nils-work]

In the Common Field Types section, change the value in the Valid Examples column for the URIString type:

- "http://www.google.com"
+ "https://www.example.com"

[nils-work]

A documentation change has also been posted on the Staging repository: #413 - Merge Change Log and Archives sections

[markverstege]

In the section Data Recipients calling Data Holders, the first bullet point appears to be redundant and could be removed - the second point seems to state the same requirement more clearly (change highlighted here).

There is a typo in the first sentence of the third point. Make the following change:

- authorisation_code
+ authorization_code

This issue has been staged for review: https://github.com/ConsumerDataStandardsAustralia/standards-staging/commit/59db12da27f91a7cc868037c50426ac408987292

[markverstege]

In the Security Profile section > Data Recipients calling Data Holders, the requirements in the first two bullet points appear to be repeated. The highlighted text in the statements is identical:

The proposal is to remove the first bullet point:

• The client ID represents the ID issued to the Data Recipient Software Product by the Data Holder upon successful dynamic client registration.

This issue has been staged for review: https://github.com/ConsumerDataStandardsAustralia/standards-staging/commit/0f6604bed1811a6d755af89342da953d58da1741

[markverstege]

In the Common Field Types section, change the value in the Valid Examples column for the URIString type:

- "http://www.google.com"
+ "https://www.example.com"

This issue has been staged for review: https://github.com/ConsumerDataStandardsAustralia/standards-staging/commit/53c9ace73285cbe10eff1c3e6dfb218d777368c7

[markverstege]

There appears to be a copy/paste error in the description of the tariffUType field in the EnergyPlanSolarFeedInTariffV3 schema:

- The type of the payer
+ Reference to the applicable tariff structure.

This issue has been staged for review: https://github.com/ConsumerDataStandardsAustralia/standards-staging/commit/9c0ae785111ec513ba4f693ab73383356c60d89d

[nils-work]

Documentation updates:

• #410 - Clarify RateString description and examples
• #411 - Fix typos

These have been staged -

• Staging #410 - Update details in Common Field Types section
• Staging #411 - Fixed typos

[nils-work]

The "Reference to the applicable [type] structure." convention could be applied to all ...UType field descriptions for consistency and clarity of interpretation.

The following sample shows the current variation across schemas:

• The type of recurrence used to define the schedule.
• The type of structure to present account specific fields.
• Indicator of the type of transaction object present in this record
• The type of address object present
• The type of object present in this response (from EnergyPaymentSchedule)
• Type of object included that describes the payee in detail.
• The type of customer object that is present
• Type of account object included.

This will be deferred to a later MI - #434 - Apply consistent UType field descriptions

[nils-work]

A documentation change has also been posted on the Staging repository: #413 - Merge Change Log and Archives sections

This has been staged - Merged the Change Log and Archives sections

[nils-work]

Incorporated into Standards v1.32.0.