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

TBD: Ignore empty elements #16

Closed Echsecutor closed 4 years ago

Echsecutor commented 4 years ago

sonething like <epcList/> being present or not corresponds to the same EPCIS event, hence should be ignored in hashing (it may even be dropped when converting from XML to JSON).

On the other hand, currently there are some flag tags being used, in particular in vendor extensions, i.e. presence or absence of a <namespace:flag/> may well have semantic meaning, i.e. make a different event

RalphTro commented 4 years ago

Agreed, @Echsecutor ! If there are no EPCs, we should ignore the epcList tag, i.e. not making it part of the pre-hash string.
It is anyway just a legacy issue in the EPCIS XSD due to ensuring backwards-compatibility with former versions where epcList was specified to be mandatory. We otherwise would run into the risk that solution providers solely working with JSON (where epcList does not need to be present if there are no serialised identifiers) may get confused.

Echsecutor commented 4 years ago

So, we should remove empty standard tags, but keep empty tags in vendor extensions?

RalphTro commented 4 years ago

Yes, I think that makes most sense as in case of user extensions, we just don't know the actual element hierarchy. Can you think of any concern anyone could have with that?