Open bhadley opened 3 months ago
I have raised a PACT backlog item for this feedback, see https://flat-dollar-c04.notion.site/Inconsistencies-of-Data-Types-in-Tech-Specs-faec9b0b7ded407caa2a2ee176536967
We will address these inconsistencies in the preparation of v3 (as data type changes will be backwards breaking changes). Gertjan Schuurmans (@schuur ) who recently joined the PACT team also noted data type inconsistencies, and is investigating these. He will share more when we have a proposal / corresponding ADR.
For now, consider all "Number" datatypes the JSON datatype number, meaning an integer or floating point expressed as a number (not string). Thus pcf.dqi.technologicalDQR
should be encoded as a Number (not string), as seen in the below screenshot of Example 9 from the tech specs (https://wbcsd.github.io/data-exchange-protocol/v2/#elementdef-dataqualityindicators)
Thank you for registering the issue I contacted you about!
I understand that you will address this issue in v3. Are you planning to redefine pcf.dqi.*DQR as a JSON String (Decimal type) in v3?
Thanks @mill6-plat6aux - let's await @schuur to return from OOO to indicate a proposed direction, and ultimately the PACT Tech WG will form consensus regarding the approach (which you are invited to be part of). So, more to come in September!
Thanks @bhadley and @mill6-plat6aux! We will indeed address these in v3 of the spec. I will make a proposal for the September workgroup.
Takuro Okada, from Nomura Research Institute, Ltd. has raised the following remark:
Properties that have Number in the Type column, such as version and pcf.exemptedEmissionsPercent, should be defined as JSON Number type, right?
However, even though pcf.dqi.technologicalDQR has Number in the Type column, the Specification says that it must be a Decimal type (in other words, a JSON String type), which is inconsistent.
Could you please change the Type of the pcf.dqi.*DQR properties to String? To be more consistent, the Property should be written as "technologicalDQR : Decimal".