search

RalphTro / epcis-event-hash-generator

ALGORITHM and SOFTWARE PROTOTYPE to uniquely identify/validate the integrity of any EPCIS event through a common, syntax-agnostic approach based on hashing. Takes an EPCIS Document (formatted in either XML or JSON-LD) and returns the corresponding hash value(s).
MIT License
8 stars 4 forks source link

Number format #20

Closed Echsecutor closed 4 years ago

Echsecutor commented 4 years ago

I had to correct the example JSON files by hand in order to adjust the representation of numbers in various places. In particular timestamps, such as 2019-10-21T11:00:30.000+01:00 may be written as 2019-10-21T11:00:30+01:00 which is the same number but displayed at a different precision leading to a different hash. The same happened for sensor data, e.g. <sensorReport type="gs1:Speed" value="161.0" uom="KMH"/> was translated to have a value of 161 in JSON (no .0).

Should we address this in our algorithm? E.g. remove trailing "0" after the "."? Originally I considered this out of scope, but in practice this will cause lots of trouble if we do not specify a way to canonicalize numbers.

RalphTro commented 4 years ago

Thanks for making me aware of that, @Echsecutor! For the canonicalisation, how do you like us to specify that the millisecond (SSS) part of an ISO timestamp MUST be present when building the pre-hash string? That means that even though the abbreviated version was technically correct, it MUST be padded with three zeros.

Echsecutor commented 4 years ago

This means that you are in favour of keeping this out of our algorithm but making it a requirement for the input? This was my original intention, but I am not sure if people will be happy with it... ;)

Echsecutor commented 4 years ago

As discussed: out algorithm needs to pad the timestamp to ms precision (see https://github.com/RalphTro/epcis-event-hash-generator/commit/60042f3b12f609a4fd5e900257362bafc901dcb6 ). All other figures should not have trailing 0s