Energy transaction fields should be conditional

[nils-work]

Description

The demand and otherCharges fields in EnergyBillingTransactionV3 are currently marked as 'optional', but should be 'conditional'.

Intention and Value of Change

Align the requirements to support the intended schema.

Area Affected

Energy APIs: EnergyBillingTransactionV3.

Change Proposed

Change the 'optional' fields to 'conditional'.

[mattyp]

As part of the working group's action items for MI22 (ConsumerDataStandardsAustralia/standards#364), I support this proposal and would urge considering this proposed change from optional to conditional as non-breaking because:

• The field behaviour isn't actually changing; these fields are already effectively conditional in practice. The demand field is mandatory when transactionUType equals demand, and otherCharges is mandatory when transactionUType equals otherCharges. This was already documented in the description field, so existing implementations following the documentation would already be treating these fields as conditional rather than purely optional.

• The current schema already contains explicit conditional statements in the descriptions, which aligns with the formal definition requiring that conditional fields "MUST have an associated conditional statement." The current optional designation is technically incorrect since these fields don't match the definition of optional fields that "MAY be present but this is not guaranteed."

• This change simply aligns the formal schema requirements with the existing behavioural requirements that were already specified in the field descriptions. No implementation properly following the existing documentation would need to change their code, as they would already be handling these fields according to their conditional nature.

In fact, this change could be viewed as a documentation improvement that reduces potential confusion by making the requirements more explicit and consistent across all specification elements. It helps prevent future implementations from misinterpreting these fields as purely optional when they have always had conditional requirements based on the transactionUType value.