General description of ID values

4259

A registered data format defines (at a minimum) a Primary Base ID Table (a detailed 4260

specification for registered ID tables may be found in Annex J). This base table defines 4261

the data system Identifier(s) represented by each row of the table, any Secondary ID Bits 4262

or Aux Format bits invoked by each table entry, and various implicit rules (taken from a 4263

predefined rule set) that decoding systems shall use when interpreting data encoded 4264

according to each entry. When a data item is encoded in a Packed Object, its associated 4265

table entry is identified by the entry’s relative position in the Base Table. This table 4266

position or index is the ID Value that is represented in Packed Objects. 4267

A Base Table containing a given number of entries inherently specifies the number of bits 4268

needed to encode a table index (i.e., an ID Value) in an ID List Packed Object (as the Log 4269

(base 2) of the number of entries). Since current and future data system ID Tables will 4270

vary in unpredictable ways in terms of their numbers of table entries, there is a need to 4271

pre-define an ID Value Size mechanism that allows for future extensibility to 4272

accommodate new tables, while minimizing decoder complexity and minimizing the need 4273

to upgrade decoding software (other than the addition of new tables). Therefore, 4274

regardless of the exact number of Base Table entries defined, each Base Table definition 4275

shall utilize one of the predefined sizes for ID Value encodings defined in Table I 5-5 4276

(any unused entries shall be labeled as reserved, as provided in Annex J). The ID Size 4277

Bit pattern is encoded in a Packed Object only when it uses a non-default Base ID Table. 4278

Some entries in the table indicate a size that is not an integral power of two. When 4279

encoding (into an IDLPO) ID Values from tables that utilize such sizes, each pair of ID 4280

Values is encoded by multiplying the earlier ID of the pair by the base specified in the 4281

fourth column of Table I-5-5 and adding the later ID of the pair, and encoding the result 4282

in the number of bits specified in the fourth column. If there is a trailing single ID Value 4283

for this ID Table, it is encoded in the number of bits specified in the third column of 4284

Table I-5-5. 4285

Table I 5-5: Defined ID Value sizes 4286 ID Size Bit pattern Maximum number of Table Entries

Number of Bits per single or trailing ID Value, and how encoded

Number of Bits per pair of ID Values, and how encoded

000 Up to 16 4, as 1 Base 16 value 8, as 2 Base 16 values 001 Up to 22 5, as 1 Base 22 value 9, as 2 Base 22 values 010 Up to 32 5, as 1 Base 32 value 10, as 2 Base 32 values 011 Up to 45 6, as 1 Base 45 value 11, as 2 Base 45 values 100 Up to 64 6, as 1 Base 64 value 12, as 2 Base 64 values 101 Up to 90 7, as 1 Base 90 value 13, as 2 Base 90 values 110 Up to 128 7, as 1 Base 128 value 14, as 2 Base 128 values 1110 Up to 256 8, as 1 Base 256 value 16, as 2 Base 256 values 111100 Up to 512 9, as 1 Base 512 value 18, as 2 Base 512 values 111101 Up to 1024 10, as 1 Base 1024 value 20, as 2 Base 1024 values 111110 Up to 2048 11, as 1 Base 2048 value 22, as 2 Base 2048 values 111111 Up to 4096 12, as 1 Base 4096 value 24, as 2 Base 4096 values 4287

I.5.3.1 Application Indicator subsection 4288

An Application Indicator subsection can be utilized to indicate use of ID Values from a 4289

default or non-default ID Table. This subsection is required in every IDMPO, but is only 4290

required in an IDLPO that uses the non-default format supporting multiple ID Lists. 4291

An Application Indicator consists of the following components: 4292

• A single AppIndicatorPresent bit, which if ‘0’ means that no additional ID List or 4293

Map follows. Note that this bit is always omitted for the first List or Map in an 4294

Object Info section. When this bit is present and ‘0’, then none of the following bit 4295

fields are encoded. 4296

• A single ExternalReg bit that, if ‘1’, indicates use of an ID Table from a registration 4297

other than the memory’s default. If ‘1’, this bit is immediately followed by a 9-bit 4298

representation of a Data Format registered under ISO/IEC 15961. 4299

• An ID Size pattern which denotes a table size (and therefore an ID Map bit length, 4300

when used in an IDMPO), which shall be one of the patterns defined by Table I 5-5. 4301

The table size indicated in this field must be less than or equal to the table size 4302

indicated in the selected ID table. The purpose of this field is so that the decoder can 4303

parse past the ID List or ID Map, even if the ID Table is not available to the decoder. 4304

• a three-bit ID Subset pattern. The registered data format’s Primary Base ID Table, if 4305

used by the current Packed Object, shall always be indicated by an encoded ID Subset 4306

pattern of ‘000’. However, up to seven Alternate Base Tables may also be defined in 4307

the registration (with varying ID Sizes), and a choice from among these can be 4308

indicated by the encoded Subset pattern. This feature can be useful to define smaller 4309

sector-specific or application-specific subsets of a full data system, thus substantially 4310

reducing the size of the encoded ID Map. 4311

I.5.3.2 Full/Restricted Use bits 4312

When contemplating the use of new ID Table registrations, or registrations for external 4313

data systems, application designers may utilize a “restricted use” encoding option that 4314

adds some overhead to a Packed Object but in exchange results in a format that can be 4315

fully decoded by receiving systems not in possession of the new or external ID table. 4316

With the exception of a IDLPO using the default Object Info format, one Full/Restricted 4317

Use bit is encoded immediately after each ID table is represented in the ID Map section 4318

or ID Lists section of a Data or Directory Packed Object. In a Directory Packed object, 4319

this bit shall always be set to '0' and its value ignored. If an encoder wishes to utilize the 4320

“restricted use” option in an IDLPO, it shall preface the IDLPO with a Format Flags 4321

section invoking the non-default Object Info format. 4322

If a “Full/Restricted Use” bit is ‘0’ then the encoding of data strings from the 4323

corresponding registered ID Table makes full use of the ID Table’s IDstring and 4324

FormatString information. If the bit is ‘1’, then this signifies that some encoding 4325

overhead was added to the Secondary ID section and (in the case of Packed-Object 4326

compaction) the Aux Format section, so that a decoder without access to the table can 4327

nonetheless output OIDs and data from the Packed Object according to the scheme 4328

specified in J.4.1. Specifically, a Full/Restricted Use bit set to ‘1’ indicates that: 4329

• for each encoded ID Value, the encoder added an EBV-3 indicator to the Secondary 4330

ID section, to indicate how many Secondary ID bits were invoked by that ID Value. 4331

If the EBV-3 is nonzero, then the Secondary ID bits (as indicated by the table entry) 4332

immediately follow, followed in turn by another EBV-3, until the entire list of ID 4333

Values has been represented. 4334

• the encoder did not take advantage of the information from the referenced table’s 4335

FormatString column. Instead, corresponding to each ID Value, the encoder inserted 4336

an EBV-3 into the Aux Format section, indicating the number of discrete data string 4337

lengths invoked by the ID Value (which could be more than one due to combinations 4338

and/or optional components), followed by the indicated number of string lengths, 4339

each length encoded as though there were no FormatString in the ID table. All data 4340

items were encoded in the A/N subsection of the Data section. 4341