GS1 EPC Tag Data Standard 1.6 - Indicod-Ecr

485348544855485648574858485948604861486248634864486548664867486848694870487148724873487448754876487748784879488048814882488348844885488648874888488948904891489248934894489548964897 A PO Index of m (as defined above) similarly indicates a Packed Object whoseposition is the mth position, or higher, than the limit of the previous table in thechain. If the valid instance of an ID Value is in an Addendum Packed Object, animplementation may choose to set a PO Index to point directly to that Addendum, ormay instead continue to point to the Packed Object in the chain that originallycontained the ID Value.NOTE: The first approach sometimes leads to faster searching; the second sometimesleads to faster directory updates.After the last PO Index Field, the AuxMap section ends with (at minimum) a single“ObjectOffsets Present” bit. A‘0’ value of this bit indicates that no ObjectOffsetssubsection is encoded. If instead this bit is a ‘1’, it is immediately followed by anObjectOffsets subsection, which holds a list of EBV-6 “offsets” (the number of octetsbetween the start of a Packed Object and the start of the next Packed Object). If present,the ObjectOffsets subsection consists of an ObjectOffsetsMultiplier followed by anObject Offsets list, defined as follows: An EBV-6 ObjectOffsetsMultiplier, whose value, when multiplied by 6, sets the totalnumber of bits reserved for the entire ObjectOffsets list. The value of this multipliershould be selected to ideally result in sufficient storage to hold the offsets for themaximum number of Packed Objects that can be indexed by this Directory PackedObject’s PO Index Table (given the value in the POIndexLength field, and givensome estimated average size for those Packed Objects). a fixed-sized field containing a list of EBV-6 ObjectOffsets. The size of this field isexactly the number of bits as calculated from the ObjectOffsetsMultiplier. The firstObjectOffset represents the start of the second Packed Object in memory, relative tothe first octet of memory (there would be little benefit in reserving extra space tostore the offset of the first Packed Object). Each succeeding ObjectOffset indicatesthe start of the next Packed Object (relative to the previous ObjectOffset on the list),and the final ObjectOffset on the list points to the all-zero termination pattern wherethe next Packed Object may be written. An invalid offset of zero (EBV-6 pattern“000000”) shall be used to terminate the ObjectOffset list. If the reserved storagespace is fully occupied, it need not include this terminating pattern. In applications where the average Packed Object Length is difficult to predict, thereserved ObjectOffset storage space may sometimes prove to be insufficient. In thiscase, an Addendum Packed Object can be appended to the Directory Packed Object.This Addendum Directory Packed Object may contain null subsections for all but itsObjectOffsets subsection. Alternately, if it is anticipated that the capacity of the POIndex Table will also eventually be exceeded, then the Addendum Packed Object mayalso contain one or more non-null PO Index fields. Note that in a given instance of anAuxMap section, either a PO Index Table or an ObjectOffsets subsection may be thefirst to exceed its capacity. Therefore, the first position referenced by anObjectOffsets list in an Addendum Packed Object need not coincide with the firstposition referenced by the PO Index Table of that same Addendum. Specifically, inan Addendum Packed Object, the first ObjectOffset listed is an offset referenced tothe last ObjectOffset on the list of the “parent” Directory Packed Object.Copyright ©2005- 2011 GS1 AISBL, All Rights Reserved. Page 189 of 218