# Enhanced TV Binary Interchange Format

Enhanced TV Binary Interchange Format (EBIF) is a multimedia content format defined by a specification developed under the OpenCable project of CableLabs (Cable Television Laboratories, Inc.). The primary purpose of the EBIF content format is to represent an optimized collection of widget and byte code specifications that define one or more multimedia pages, similar to web pages, but specialized for use within an enhanced television or interactive television system.
An EBIF resource (file), i.e., a sequence of bytes that conforms to the EBIF content format, forms the primary information contained in an ETV Application. An ETV User Agent acquires, decodes, presents (widgets), and executes (actions) contained in an EBIF resource in order to present a multimedia page to an end-user. Other types of more specialized EBIF resources play auxiliary roles to this principal role of encoding viewable and interactive pages.

## Common Resource Format

An EBIF resource consists of the following components:
* Resource Header
* Optional Common Section
* Optional Platform Section 1...N
A common or platform section of an EBIF resource consists of the following constructs:
* Section Header
* Table Directory
* Table 0...N-1
* Optional Heap

## Tables

The following table types are defined for use with EBIF:
* Action
* Generic Data
* Metadata
* Palette
* Platform Directory
* Reference
* Resource Locator
* Trigger
* Widget
In addition to the above, an EBIF resource may include one or more private use tables that may be interpreted or used by specific user agents.

## Widgets

The following types of widgets are defined for use with EBIF:
* Button
* Collection
* Container
* Form
* Hidden
* Hot Spot
* Image
* Multi-Line Text
* Page
* Private Use
* Radio
* Radio Group Container
* Rectangle
* Selector
* Text
* Text Input
* Timer
* Video

## Actions

In an EBIF resource, programmatic (procedural) information takes the form of byte code, where each operation and its (optional) operands is referred to as an action. Actions are organized into sequences by means of one or more action tables where each entry points at (1) an encoded action and (2) the action table index of the next action to execute after the current action's execution is completed. An action sequence terminates when the next action table index is a special value (0xFFFF) or in the case of certain flow of control actions. Action sequences effectively represent one or more traditional code blocks with potential internal looping behavior.
Action sequences are executed as a result of firing certain predefined events, such as a page load event, a key press event, a click event, etc. As such, all programmatic execution takes place in the context of event handlers, whose execution is serialized by an ETV User Agent.
The following categories of actions are defined by EBIF:
* Flow of Control Actions
* Predicate Actions
* Variable Store Actions
* Arithmetic Actions
* Boolean Logic Actions
* Mathematic Actions
* String Actions
* Array Actions
* Application and Page Actions
* Widget Actions
* Table Actions
* Miscellaneous Actions

### Memory Model

The action memory model is based on a variable store, and does not make use of registers or a stack. With the exception of one predefined, internal result value variable, all variables are preallocated (and typed) at compilation time. These variables are represented in the form of a table referred to as an augmented reference table, where the content of the table is initialized at compilation time, then stored and mutated at runtime by an ETV User Agent.

### Execution Model

The action execution model is based on the decoding and processing of action sequences that serve as event handlers.
Execution of action sequences are serialized through the sequential dispatching of events to event handlers, completing the execution of an action sequence functioning as an event handler before executing any other applicable event handlers (for that event) and before processing any other enqueued event.