User Extensions to standard Elements to be included into the pre-hash string

[RalphTro]

I suggest that we test the correct concatenation of all kind of user extensions that can appear as part of an EPCIS event. For that purpose, I prepared an EPCIS event which IMO should illustrate all areas in which it is possible to insert user extensions, see #12 in https://github.com/gs1/EPCIS/blob/master/XSD/SensorDataExamples.xml:

• As part of the error declaration element
• As part of readPoint/bizLocation
• As an ordinary event-level extension
• As part of the sensorElement (and its sub-elements sensorReport/sensorMetaData) In all four cases, it is possible to go for either (a) an XML element, (b) a complex XML element or (c) XML inline attributes.

[Echsecutor]

In this file there are a lot of events. I guess we should ensure that:

• ~event 1 and 2 get the same hash (they currently dont)~ event 1 and 2 may be based on the same measurements, but at different aggregation levels

• [x] all other events should be distinct (there currently is a collission)

• anything else?

[Echsecutor]

The collision was due to the first example event already being present in another example file. I have deleted the other one.

Now https://github.com/gs1/EPCIS/blob/master/XSD/SensorDataExamples.xml is part of the tests. https://github.com/RalphTro/epcis-event-hash-generator/commit/389e4c351b22f6b8d5772c503f8ceb3ee0797691

[Echsecutor]

@RalphTro the prehashes are in https://github.com/RalphTro/epcis-event-hash-generator/blob/master/tests/examples/SensorDataExamples.prehashes

Anything in particular that you are looking for?

[RalphTro]

Dear @Echsecutor ,

Thanks a lot for this! I just checked the pre-hash string of the last transformation event and came only across three issues:

(a) the user extensions in the errorDeclaration element do not yet appear. Namely:

Employee 123 34 66 (b) the inline user extensions in (1) sensorMetaData and (2) the first sensorReport element do not yet appear. Namely: (1) example:someFurtherMetaData="someText" (2) example:cv="123" (c) the user extensions below readPoint and bizLocation do not yet appear. Namely: (414)4023333000000 (414)4023333000017 (254)12 For all three points, note algorithm step no. 19 which I presented just yesterday in the EPCIS call (none of the participants disagreed). Many thanks in advance for adjusting that!

[Echsecutor]

Ah, many thanks for pointing that out! Indeed, our way of providing an explicit list with the ordering of elements to be included into the hash string leads to elements not appearing in this list to be ignored. I will change the algorithm such as to include also those unknown fields

[Echsecutor]

@RalphTro after reading 19. a few times, I still want to make sure:

• we add the mother element name before the namespace before the key
• all user extension elements are at the end of the pre hash string, not next to ("inside") their mother element

right?

[RalphTro]

Dear @Echsecutor , with regard to the second bullet point: correct

Regarding the first one and just to prevent any misunderstanding :-): What do you mean with "...before the namespace before the key"? If you consider a standard field with an extension point a "mother element " and the latter conveys a user extension, then yes: when concatenating its content to the pre-hash string, we first need to indicate the mother element (let's say "readPoint"), followed by the respective keys or key value pairs (where all keys are always prefixed with their namespace) - depending of whether it is a complex or ordinary element.

So, concatenation in this case works similarly as with e.g. event-level extensions - the only difference is that the entire sub-string needs to be singularly prefixed with the mother/standard element's name.

Was I able to answer your question? ;-)

If you think that the wording of #19 should be improved, please let me know!

[Echsecutor]

Many thanks! I think I got it. ;)

[Echsecutor]

fixed in https://github.com/RalphTro/epcis-event-hash-generator/pull/34