Closed clementh59 closed 1 year ago
Dear @clementh59 ,
Another good catch - thanks a lot! When this was implemented, there was no final consensus yet as to the URI structure. We also need to think how the short strings for all CBV standard elements (e.g. shipping
instead of https://ns.gs1.org/cbv/BIZSTEP-shipping
- which will be allowed in JSON/JSON-LD, but not in XML), will impact the construction of the pre-hash string.
This is another thing which was added after the SW package was published. While it makes other things easier, it complicates the construction of the pre-hash string.
How do you like the following suggestion: let's wait until the draft spec are motioned to Public Community Review (expected by End of September), by which time all this should be pretty stable, and then build in an appropriate update?
@Echsecutor : let's discuss on how this could be tackled some time after your holiday. As I do not want us to update the algorithm everytime some values are added to the CBV, my spontaneous thought on how this could be solved quite nicely would be to strip off 'urn:epcglobal:cbv:bizstep:' everytime a URN is recognised in an XML document and to copy and paste the value 1:1 from a JSON/JSON-LD structure.
Kind regards, @RalphTro
Dear @RalphTro ,
We also need to think how the short strings for all CBV standard elements (e.g. shipping instead of https://ns.gs1.org/cbv/BIZSTEP-shipping - which will be allowed in JSON/JSON-LD, but not in XML), will impact the construction of the pre-hash string.
Yes, good catch too.
How do you like the following suggestion: let's wait until the draft spec are motioned to Public Community Review (expected by End of September), by which time all this should be pretty stable, and then build in an appropriate update?
Yes, good idea.
Best regards,
Clément
@RalphTro since we where talking about the "short string" version today: How about your above suggestion to use the short string version as the canonical form? The transformation leading here (detecting and removing the CBV URN prefixes) should be the easiest to implement.
New Examples by Ralph in https://github.com/RalphTro/epcis-event-hash-generator/pull/66 -> Continue work on this issue in that PR!
Update Dear @clementh59 , This issue can be closed from my POV - when executing the code (master branch) for e.g. a JSON/JSON LD file accommodating bare string notation, it neatly expands to its canonical form (e.g. "in_progress"--> "https://ref.gs1.org/cbv/Disp-in_progress") Would you agree with this? Kind reards, Ralph
Yes, I do!
Thanks a lot, Clément
Hi,
https://github.com/RalphTro/epcis-event-hash-generator/blob/ff05d4782959b4a3087dbf61bec0f1b951844125/epcis_event_hash_generator/hash_generator.py#L138 https://github.com/RalphTro/epcis-event-hash-generator/blob/ff05d4782959b4a3087dbf61bec0f1b951844125/epcis_event_hash_generator/hash_generator.py#L140 https://github.com/RalphTro/epcis-event-hash-generator/blob/ff05d4782959b4a3087dbf61bec0f1b951844125/epcis_event_hash_generator/hash_generator.py#L142 https://github.com/RalphTro/epcis-event-hash-generator/blob/ff05d4782959b4a3087dbf61bec0f1b951844125/epcis_event_hash_generator/hash_generator.py#L144
Shouldn't it be
https://ns.gs1.org/cbv/XXX-
like detailled in the readme?