Closed clementh59 closed 1 year ago
sboeckelmann
commented
1 year ago Dear @Aravinda93, while you're at it; can you please also make our prehash String match with @clementh59 . That would be very helpful for testing and comparing future changes.
Aravinda93
commented
1 year ago @clementh59 Thanks for reporting, we are looking into it and we will update you as soon as we have fixed the issue.
@sboeckelmann Surely, I will change the pre-hash string display to match @clementh59
sboeckelmann
commented
1 year ago Surely, I will change the pre-hash string display to match @clementh59
Thank you! If our two projects are using the same presentation for the pre-hash strings then this is like a de-facto standard representation, which should also be used by others as well. I think @RalphTro implementation already is a match. But we should try to have the same representation for all of them.
clementh59
commented
1 year ago We didn't add any support for pre-hash string, I have to update a bit our code to generate it, so I wouldn't change your implementation in prod just to match ours. But if it helps for comparing, please do it! I think yours is quite clear.
sboeckelmann
commented
1 year ago We didn't add any support for pre-hash string, I have to update a bit our code to generate it, so I wouldn't change your implementation in prod just to match ours.
Alright, so we will put it on hold for now. @Aravinda93 can you compare ours with the python implementation from @RalphTro?
We should all try to use the same format for identifying differences with ease.
Aravinda93
commented
1 year ago @sboeckelmann I looked into the @RalphTro Python based implementation and the pre-hash string there matches to the pre-hash string provided by @clementh59 so I will change our code to match their format.
clementh59
commented
1 year ago Hi, just a heads up that I updated the issue content. I slightly updated our algorithm since we had an issue with rule 20.
Aravinda93
commented
1 year ago @clementh59
Thanks a lot for the update. We have completed the changes based on your suggestion and currently going through all the rules once again to ensure everything correct and nothing is missed.
Aravinda93
commented
1 year ago @clementh59
I thought of using your JS project https://github.com/evrythng/epcis2.js and comparing some of the prehash string from our code with yours as part of testing so I tried to add your JS project as dependency to a sample Nuxtjs project.
When I try to import it within a sample project then I get the error:
ERROR in ./node_modules/epcis2.js/dist/epcis2.browser.js 8:392504
Module parse failed: Unexpected token (8:392504)Following is the Vue page that I created as a sample:
<template>
<div>
<h1>Testing Pre-Hash for Event Hash</h1>
</div>
</template>
<script>
import Vue from 'vue'
import {objectToEvent, ObjectEvent, AggregationEvent} from 'epcis2.js'
export default Vue.extend({
mounted() {
const object = {
type: 'ObjectEvent',
eventTime: '2005-04-03T20:33:31.116-06:00',
eventTimeZoneOffset: '-06:00',
epcList: ['urn:epc:id:sgtin:0614141.107346.2017'],
action: 'OBSERVE',
bizStep: 'shipping',
readPoint: {
id: 'urn:epc:id:sgln:0614141.07346.1234',
}
};
const event = objectToEvent(object);
console.log(event instanceof ObjectEvent) // true
console.log(event instanceof AggregationEvent) // false
console.log(event.toString());
console.log("MOUNTED : " + JSON.stringify(object, null, 4))
},
created() {
console.log("CREATED")
}
})
</script>Just wanted to confirm if I have to do something or is there any other direct way I can use this project and generate prehash for testing.
clementh59
commented
1 year ago @Aravinda93
I've never tested the package with Vuejs, and I am not familiar with this framework neither, I am sorry.
However, you wouldn't have the very last version, even though it was working. What I recommend you to do is: Download: https://github.com/evrythng/epcis2.js/tree/pre-hash-comparison Go on the pre-hash-comparison branch.
npm i npm run build cd example/node_example node example_with_creation_from_object.js
You can update the JSON in the file to test what you want to test.
By default, we don't show the pre-hash, so I did a branch to be able to see it.
Aravinda93
commented
1 year ago @clementh59
Thanks a lot for quick response. The above provided approach is working as expected so I will continue with this and try to compare the pre-hash string.
clementh59
commented
1 year ago Hi @Aravinda93,
Any news on the comparison? Did you find differences?
Aravinda93
commented
1 year ago Hello @clementh59
We are working on the changes and we have made many changes with regards to order and formatting of the values. I have also compared the pre-hash string for some of the EPCIS document with your tool to ensure everything is working correctly. All the changes are present in the feature branch currently OEPCIS-494-fixing_issues_based_on_hash_id_rules.
We will do couple of more tests and then finally merge it to main and update you.
clementh59
commented
1 year ago Great, thanks for the update
Aravinda93
commented
1 year ago Hello @clementh59
Here are a few observations that I have found out during the comparison of our application with your JS application:
sensorReport -> bizRules as part of the standard element, hence it's including it as a part of user extensions. As per JSON schema bizRules is part of a standard element so I believe it should appear after the dataProcessingMethod under the sensorReport. What do you suggest?For following JSON document:
{
"@context": [
"https://gs1.github.io/EPCIS/epcis-context.jsonld"
],
"id": "https://id.example.org/document1",
"type": "EPCISDocument",
"schemaVersion": "2.0",
"creationDate": "2005-07-11T11:30:47.0Z",
"epcisBody": {
"eventList": [
{
"type": "ObjectEvent",
"eventTime": "2019-10-07T15:30:00.000+01:00",
"eventTimeZoneOffset": "+01:00",
"epcList": ["urn:epc:id:sgtin:0614141.107346.2018"],
"action": "ADD",
"bizStep": "packing",
"disposition": "in_progress",
"readPoint": {
"id": "urn:epc:id:sgln:4012345.00025.0"
},
"sensorElementList": [
{
"sensorMetadata": {
"startTime": "2019-04-01T15:00:00.000+01:00",
"endTime": "2019-04-02T14:59:59.999+01:00"
},
"sensorReport": [
{
"type": "Temperature",
"uom": "CEL",
"time": "2019-07-19T14:00:00.000+01:00",
"deviceID": "urn:epc:id:giai:4000001.111",
"deviceMetadata": "https://id.gs1.org/8004/4000001111",
"rawData": "https://example.org/8004/401234599999",
"dataProcessingMethod": "https://example.com/253/4012345000054987",
"bizRules": "https://example.org/253/4012345000054987"
}
]
}
]
}
]
}
}Prehash string and hash-id from our application:
ni:///sha-256;284dd456aa6683e755c1502af6215c215cab1627c27a933e728cce3163f1c81b?ver=CBV2.0
eventType=ObjectEvent
eventTime=2019-10-07T14:30:00.000Z
eventTimeZoneOffset=+01:00
epcListepc=https://id.gs1.org/01/10614141073464/21/2018
action=ADD
bizStep=https://ref.gs1.org/cbv/BizStep-packing
disposition=https://ref.gs1.org/cbv/Disp-in_progress
readPointid=https://id.gs1.org/414/4012345000252
sensorElementListsensorElementsensorMetadatastartTime=2019-04-01T14:00:00.000Z
endTime=2019-04-02T13:59:59.999Z
sensorReporttype=https://gs1.org/voc/Temperature
deviceID=https://id.gs1.org/8004/4000001111
deviceMetadata=https://id.gs1.org/8004/4000001111
rawData=https://id.gs1.org/8004/401234599999
dataProcessingMethod=https://id.gs1.org/253/4012345000054987
bizRules=https://id.gs1.org/253/4012345000054987
time=2019-07-19T13:00:00.000Z
uom=CELPrehash string from your application:
ni:///sha-256;138dfab21ff41d1842e55a6a5f1f7509fc7210a1a846547f71b57b2b004cd85b?ver=CBV2.0
eventType=ObjectEvent
eventTime=2019-10-07T14:30:00.000Z
eventTimeZoneOffset=+01:00
epcListepc=https://id.gs1.org/01/10614141073464/21/2018
action=ADD
bizStep=https://ref.gs1.org/cbv/BizStep-packing
disposition=https://ref.gs1.org/cbv/Disp-in_progress
readPointid=https://id.gs1.org/414/4012345000252
sensorElementListsensorElementsensorMetadatastartTime=2019-04-01T14:00:00.000Z
endTime=2019-04-02T13:59:59.999Z
sensorReporttype=https://gs1.org/voc/Temperature
deviceID=https://id.gs1.org/8004/4000001111
deviceMetadata=https://id.gs1.org/8004/4000001111
rawData=https://id.gs1.org/8004/401234599999
dataProcessingMethod=https://id.gs1.org/253/4012345000054987
time=2019-07-19T13:00:00.000Z
uom=CEL
sensorElementListsensorElementsensorReportbizRules=https://id.gs1.org/253/4012345000054987For the following EPCIS document:
{
"@context": [
"https://gs1.github.io/EPCIS/epcis-context.jsonld"
],
"type": "EPCISDocument",
"schemaVersion": "2.0",
"creationDate": "2019-11-28T14:59:02.000+01:00",
"epcisBody": {
"eventList": [
{
"type": "AssociationEvent",
"eventTime": "2019-11-01T13:00:00.000Z",
"eventTimeZoneOffset": "+01:00",
"parentID": "urn:epc:id:sgtin:5787854.778785.47834",
"childEPCs": [
"urn:epc:id:giai:4000001.12345"
],
"action": "ADD",
"bizStep": "assembling",
"readPoint": {
"id": "urn:epc:id:sgln:4012345.00001.123"
}
}
]
}
}Prehash string and hash id from our application:
ni:///sha-256;2116ddb0265bb7be32e5ccf55648cd614a18d8c0e76ae7247008e06cf336f93f?ver=CBV2.0
eventType=AssociationEvent
eventTime=2019-11-01T13:00:00.000Z
eventTimeZoneOffset=+01:00
parentID=https://id.gs1.org/01/75787854787854/21/47834
childEPCsepc=https://id.gs1.org/8004/400000112345
action=ADD
bizStep=https://ref.gs1.org/cbv/BizStep-assembling
readPointid=https://id.gs1.org/414/4012345000016/254/123Prehash string and hash id from your application:
ni:///sha-256;02ba339bb3c39f7d1b0730765074d9968b7b2df227b3f8e073429a13463c353a?ver=CBV2.0
eventType=AssociationEvent
eventTime=2019-11-01T13:00:00.000Z
eventTimeZoneOffset=+01:00
parentID=https://id.gs1.org/01/75787854787854/21/47834
childEPCsepc=https://id.gs1.org/8004/400000112345
action=ADD
bizStep=https://ref.gs1.org/cbv/BizStep-assembling
readPointid=https://id.gs1.org/414/4012345000016/254/123Hashid from the online tool:
2116ddb0265bb7be32e5ccf55648cd614a18d8c0e76ae7247008e06cf336f93fApart from this, I believe rest everything seems to be working correctly. I will create a PR and inform you after the merge and deployment so you can test again and confirm.
clementh59
commented
1 year ago @Aravinda93
First of all thanks a lot for the feedback, this is much appreciated.
bizRules are not included in the canonical order of a sensorReport, even though it is included in the schema. I raised this issue a few months ago to Mark and Craig, from GS1. They told me that the schema had indeed an issue. According to the standard, bizRules shouldn't be a standard field of a sensorReport, but only of sensorMetadata, which is why it is added at the end of the pre-hash string. (Please notice that if you try epcisDocument.isValid() on the provided document, with our SDK, it will say that it isn't valid due to this).If you check here: https://ref.gs1.org/epcis/bizRules. It only mentions sensorMetadata too.
I think there were another inconsistency in the schema they release, which I fixed in mine. You can see it there if you want to compare.
Aravinda93
commented
1 year ago @clementh59
Thanks for the quick response.
If you have already confirmed regarding this then I will remove it from our implementation for sensorReport as well. I was under the impression that JSON schema is up to date. I have already observed that it is not present within standard (https://ref.gs1.org/standards/cbv/) but I was not relying on it as it already contains many missing information such as exception, coordinateReferenceSystem, certificationInfo, etc.
clementh59
commented
1 year ago You are right, it misses some fields which have to be ignored by the algo. Maybe my reference wasn't super clear in this case, but for bizRules, this is not a "missing field", since it is not really in sensorReport.
Aravinda93
commented
1 year ago @clementh59
Surely, I will change it. One more thing I have noticed is that during pre-hash generation for the exception field you are currently doing something like this: https://gs1.org/voc/SensorAlertType-ALARM_CONDITION but when I check the standard there they have mentioned just the https://gs1.org/voc/ALARM_CONDITION. We believe second is the correct as that URL is reachable.
Can you once confirm which is the correct:
exception=https://gs1.org/voc/ALARM_CONDITION`
exception=https://gs1.org/voc/SensorAlertType-ALARM_CONDITION@Aravinda93 Good catch! I've updated the branch that you are using to compare! Thanks a lot. Since https://gs1.org/voc/ALARM_CONDITION is reachable, my guess is indeed that it is the correct one.
Hi,
I compared again the outputs of our algorithms and I think you forgot a few rules that are listed in the official algorithm (in the cbv standard).
For example, you don't order pre-hash strings based on case-sensitive lexical ordering. You also don't support the new GS1 Web URI ( 'https://ref.gs1.org/cbv' ).
Here is an example of an output of our algorithm:
Here is the associated document:
Here is yours:
I am sorry, I know we don't have the same indentation format for the pre-hash string, but I hope it still helps!