GS1 EPC Tag Data Standard 1.6 - Indicod-Ecr

431043114312431343144315431643174318431943204321432243234324432543264327432843294330433143324333433443354336433743384339434043414342434343444345434643474348434943504351sector-specific or application-specific subsets of a full data system, thus substantiallyreducing the size of the encoded ID Map.I.5.3.2 Full/Restricted Use bitsWhen contemplating the use of new ID Table registrations, or registrations for externaldata systems, application designers may utilize a “restricted use” encoding option thatadds some overhead to a Packed Object but in exchange results in a format that can befully decoded by receiving systems not in possession of the new or external ID table.With the exception of a IDLPO using the default Object Info format, one Full/RestrictedUse bit is encoded immediately after each ID table is represented in the ID Map sectionor ID Lists section of a Data or Directory Packed Object. In a Directory Packed object,this bit shall always be set to '0' and its value ignored. If an encoder wishes to utilize the“restricted use” option in an IDLPO, it shall preface the IDLPO with a Format Flagssection invoking the non-default Object Info format.If a “Full/Restricted Use” bit is ‘0’ then the encoding of data strings from thecorresponding registered ID Table makes full use of the ID Table’s IDstring andFormatString information. If the bit is ‘1’, then this signifies that some encodingoverhead was added to the Secondary ID section and (in the case of Packed-Objectcompaction) the Aux Format section, so that a decoder without access to the table cannonetheless output OIDs and data from the Packed Object according to the schemespecified in J.4.1. Specifically, a Full/Restricted Use bit set to ‘1’ indicates that: for each encoded ID Value, the encoder added an EBV-3 indicator to the SecondaryID section, to indicate how many Secondary ID bits were invoked by that ID Value.If the EBV-3 is nonzero, then the Secondary ID bits (as indicated by the table entry)immediately follow, followed in turn by another EBV-3, until the entire list of IDValues has been represented. the encoder did not take advantage of the information from the referenced table’sFormatString column. Instead, corresponding to each ID Value, the encoder insertedan EBV-3 into the Aux Format section, indicating the number of discrete data stringlengths invoked by the ID Value (which could be more than one due to combinationsand/or optional components), followed by the indicated number of string lengths,each length encoded as though there were no FormatString in the ID table. All dataitems were encoded in the A/N subsection of the Data section.I.5.4 ID Values representation in an ID Value-list Packed ObjectEach ID Value is represented within an IDLPO on a list of bit fields; the number of bitfields on the list is determined from the NumberOfIDs field (see Table I 5-1). Each IDValue bit field’s length is in the range of four to eleven bits, depending on the size of theBase Table index it represents. In the optional non-default format for an IDLPO’s ObjectInfo section, a single Packed Object may contain multiple ID List subsections, eachreferencing a different ID Table. In this non-default format, each ID List subsectionconsists of an Application Indicator subsection (which terminates the ID Lists, if it beginswith a ‘0’ bit), followed by an EBV-3 NumberOfIDs, an ID List, and a Full/RestrictedUse flag.Copyright ©2005- 2011 GS1 AISBL, All Rights Reserved. Page 175 of 218