List of predefined units

[sieukrem]

In the Table 20 there is list of predefined units. According to this table kWh and Wh can be used for delivered energy.

Is it allowed to use other units like mWh, dWh?

The reasons behind this question are the conversion errors caused by JSON parsers, during reading of floating point numbers.

• JSON does not restrict the precision of the number (see Interoperability section of JSON on wikipedia), which is used as value by RV.
• Most of parsers, would parse number like 9.2 into double representation 9.1999999999999992894572642399E0 and cause issues at next transition to textual representation.
• Most of parsers, would parse number like 92 into integer representation 92 and not cause any issues at next transition to textual representation.

Some certification authorities require precision up to dWh for measurement and representation to customer. Usage of integer representation would be beneficial in such cases, for calculation and text->number->text transformation.

[ahzf]

You should not extend your implementation weaknesses onto the protocol specification. Just use Decimal instead of Double, there you have two Integers ;) Might not work out-of-the-box, but as nearly every JSON library is Open Source you can fix this and send the result upstream.

[sieukrem]

You should not extend your implementation weaknesses onto the protocol specification. Just use Decimal instead of Double, there you have two Integers ;) Might not work out-of-the-box, but as nearly every JSON library is Open Source you can fix this and send the result upstream.

I agree that the contribution to Open Source is a possible way!

• not all of libraries would accept such changes (performance, breaking changes, legacy, ...)
• not all of OCMF users can go this path (3rd party, ...)

I still think that it is worth to have a conversation here about this topic, because OCMF builds an interface between CS and CSMS. In the mentioned wiki article the section about interoperability states "While the specifications place no limits on the magnitude or precisions of JSON number literals, the widely-used JavaScript implementation stores them as IEEE754 "binary64" quantities. For interoperability, applications should avoid transmitting numbers which cannot be represented in this way, for example 1E400 or 3.141592653589793238462643383279"

The OCMF specification needs to admit this constraint and propose a regulation way. Either it is a declaration of RV to be interpreted as decimal, despite of the number nature. Or OCMF keeps the number as JSON it specifies but uses RU as application layer extension point and allows other units to achieve the precision goals.