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

support for ignoring industry/repository specific fields #114

Closed dakbhavesh closed 3 months ago

dakbhavesh commented 4 months ago

Dear @RalphTro,

This PR is to address #109 . Please have a look and share your feedback. Please note that I have kept the key and schema as per below as discussed

"repository-x": "https://repository-x.example.com/"

RalphTro commented 4 months ago

Super, @dakbhavesh ! Many thanks. I reserved some time for testing this in my calendar and will keep you posted.

RalphTro commented 4 months ago

Dear @dakbhavesh , Happy to report that all tests with JSON/JSON-LD files were successful. So, MANY THANKS for this!

A follow-up question: do we also want to support this feature in XML? If yes, how do you envision to list the fields to be ignored?

I drafted/tested the following XML query doc:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <ns4:QueryResults xmlns:epcis="urn:epcglobal:epcis:xsd:1"
         xmlns:ns3="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader"
         xmlns:ns4="urn:epcglobal:epcis-query:xsd:1" xmlns:example="https://ns.example.com/epcis/"
         xmlns:repository-x="https://repository-x.example.com/">
         <queryName>SimpleEventQuery</queryName>
         <resultsBody>
            <EventList>
               <ObjectEvent>
                  <eventTime>2015-03-30T10:58:56.591+02:00</eventTime>
                  <recordTime>2015-03-30T15:38:32.052+02:00</recordTime>
                  <eventTimeZoneOffset>+02:00</eventTimeZoneOffset>
                  <epcList />
                  <action>ADD</action>
                  <bizStep>urn:epcglobal:cbv:bizstep:commissioning</bizStep>
                  <readPoint>
                     <id>urn:epc:id:sgln:4054738.00005.0</id>
                  </readPoint>
                  <extension>
                     <quantityList>
                        <quantityElement>
                           <epcClass>urn:epc:class:lgtin:4054739.099961.2015-03-30a</epcClass>
                           <quantity>150</quantity>
                           <uom>KGM</uom>
                        </quantityElement>
                     </quantityList>
                  </extension>
                  <example:testField1>123</example:testField1>
                  <example:testField2>ABC</example:testField2>
               </ObjectEvent>
            </EventList>
         </resultsBody>
         <repository-x:ignoreFields>
            <example:testField1 />
         </repository-x:ignoreFields>
      </ns4:QueryResults>
   </soap:Body>
</soap:Envelope>

This doesn't work though like in JSON/JSON-LD.

Many thanks in advance for sharing your thoughts.

Kind regards, Ralph

dakbhavesh commented 4 months ago

Dear @RalphTro, Your proposal for mentioning fields to ignore in hash calculation for XML doc seems fine to me. I will try to incorporate that in logic as soon as possible.

Thanks for your patience.

RalphTro commented 4 months ago

Super. Many thanks, @dakbhavesh!

RalphTro commented 3 months ago

Good morning @dakbhavesh, Thanks so much for this! All the tests I conducted were successful. For the time being, I am happy to accept/merge this PR. We may revisit the implementation (and slightly adjust the code) if @Echsecutor can present compelling use cases for the (formerly discussed) option to indicate fields to be ignored in the event hash ID. If so, we need to discuss how this should work if the eventID field is populated with a UUID URI by the EPCIS capture application. At this moment of time, I personally still think that having a field in the EPCIS document that specifies all fields to be disregarded is the better option. But let's see. Anyway - again MANY THANKS for this and wishing you a great week ahead! Kind regards, Ralph