| Active Widget |
Widget in full or minimized view, receptive for data updates |
| API (Application Programming Interface) |
An interface that is provided to the application in order to support the application’s request towards the execution environment. In detail an API consists of all classes, interfaces, methods, constructors, parameters, return values and exceptions that are required to provide the given functionality |
| API Addition |
The set of APIs is not fixed, and is expected to be extended over time, as new features become supportable (and perhaps also as features become obsolete). An example of this might be the creation of a SIM access API where none existed initially. |
| API Evolution |
Any individual API can itself evolve over time, to reflect new device capabilities, or new use cases, or to correct errors or shortcomings in earlier API versions. Each individual API might be associated with a version number. |
| Application |
OMTP uses a broad definition of “Application” in this document. |
| Application Widget |
Rendered as an Application in its own window |
| Browser |
An Application that allows a user to access and view Web Pages. It is able to process and render Web Pages or any other content formats |
| Capability Discovery |
Mechanisms/APIs by which application can discover underlying capability, upon which its future execution may depend. Capability Discovery can be divided into the following types |
| Capability Discovery - API discovery |
Discovery of the APIs which may be present on the phone which the application can use |
| Capability Discovery - Application Discovery |
Discovery of other Applications that are resident on the phone. Of particular relevance to catalogue and Installation type Applications |
| Capability Discovery - Device based capability discovery |
Discovery of device resident capabiliy such as Codec support |
| Capability Discovery - Network based capability discovery |
Discovery of services that are resident on the network |
| Decentralised API Definition |
The definition of APIs is not limited to any central body such as a standards organisation; instead, APIs can be defined and published (and, obviously, implemented, but not necessarily portably) by any independent entity. APIs might be defined by device manufacturers, network operators, special interest bodies (e.g. the Bluetooth SIG) or individual service providers or publishers. This requires that a system of identifiers exists for APIs which allows for decentralised management. A common way to do this is to use URIs as API identifiers. |
| Desktop/Phonetop widgets |
Rendered with a built-in Application such as idle Application or desktop window |
| Downloaded Widget |
A Widget that is executed directly from a remote website |
| Dynamic API Provisioning |
The ability to enable an API on a device when the device is in the field, via some specific extension mechanism. (This doesn’t include general extension mechanisms such as re-flashing the entire device.) The specific extension mechanism might be a mechanism supported by the operating system (e.g. ActiveX), or a mechanism that is internal to the Browser (such as Browser extensions or plugins). There could be other implementation methods including local HTTP servers. |
| Execution |
Occurs after Installation and Loading. The point in time begins when the Terminal starts the Application |
| Execution Environment |
A set of hardware and software components that provide facilities (e.g. computing, memory management, input/output, etc.), necessary to support Applications |
| Hybrid Application |
Applications that are authored using web formats that rely on a combination of locally and remotely hosted pages/files. |
| Hybrid Widget |
A Widget that has been through an Installation event but includes remote page |
| Installation |
The point when a package of software, that may contain one or more items of code and data, is integrated with the EE prior to Loading and Execution. Typically the software package will be resident in low speed memory, such as a file system or local database, after Installation |
| Installed Widget |
A Widget that has gone through an Installation event |
| Loading |
The process of moving installed code into high-speed Execution memory. This could occur a long time prior to Execution. In some Terminals, this phase is just a matter of preparing the EE as the Execution memory is the same as the Installation memory |
| Manufacturer |
The company that holds the warranty for the Terminals being sold in the market |
| Platform API |
Application Programming Interfaces (API) exposed by the native platform of the terminal |
| Remote De-installation Service |
The Remote De-installation Service initiates the Widget resource de-installation of an installed Widget resource |
| Remote Installation Service |
The Remote Installation Service initiates the Widget resource Installation of a Widget resource |
| Remote Update Service |
The Remote Update Service initiates the Widget resource version update of an installed Widget resource |
| Roaming Mode |
The Terminal is attached to a visited cellular network which is not the home cellular network |
| Scriptable APIs |
APIs that expose device functionality to scripts within Web Applications. The exact set of scriptable APIs that will be exposed and the method via which they will be exposed is for further study. |
| Security Framework |
The set of security capabilities responsible for ensuring Scriptable APIs are accessed in a controlled manner. |
| Standardised API Provisioning |
A portably defined and widely supported mechanism for dynamic provisioning which enables implementations of APIs to be deployed to a range of dissimilar devices, without specific intervention or support by the device manufacturer – beyond implementing support for the standardised mechanism in the first place. |
| Start file |
The Start File is the first file that is instantiated after the configuration file was processed |
| Terminal |
Used as an alternative term for a cellular telephone, device, handset, mobile equipment, user equipment or phone |
| Tookit Widgets |
A Widget rendered within a Web Page that constitutes a core navigtional component |
| Web Application |
An Application authored using web formats that makes use of Scriptable APIs, e.g. an installed Widget, web based Application or hybrid. |
| Web Page |
HTML or XHTML content that references further objects like Cascading Style Sheets (CSS), ECMAScript and graphics in various formats like PNG and GIF89 |
| Web Page Provisioning Server |
Web server that provides a Web Page for downloading |
| Web Runtime Core |
A software module that knows how to parse and execute browser formats (e.g. HTML and JavaScript), render web content to a display surface, and process user interaction (e.g. via keypad or touch screen) with that content. Installed Widgets, web based Applications, and hybrids will all typically use a WRE to render their content. Multiple Web Runtimes Environments may be installed on a device. |
| Web Runtime Environment |
A software module that parses and executes browser formats (e.g. HTML and JavaScript), render web content to a display surface, and process user interaction (e.g., via keypad or touch screen) with that content. Installed widgets, web based applications, and hybrids will all typically use a WRE to render their content. Multiple Web Runtimes Environments may be installed on a device |
| Web User Agent |
see Browser |
| Web Widgets |
Self contained Widget rendered within a Web Page containing potentially other Widgets |
| Websites |
Applications that are invoked by accessing a single remotely hosted web page. |
| Widget |
A Widget is understood to be an interactive single purpose Application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and Installation on a user's machine, mobile phone, or mobile Internet device |
| Widget Download Application |
see Browser |
| Widget Engine |
A user agent that checks the conformance of Widget resources or its configuration documents, extracts file entries from within a Widget resource’s zip archive, renders various graphics formats, parses XML applications, manages a Document Object Model (DOM) and optionally supports HTTP, HTML, ECMAScript, CSS and other formats and specifications. |
| Widget ID |
According to [2], the Widget ID is a valid URI that specifies a unique identifier specific to the Widget Resource |
| Widget List |
The Widget List contains a reference to each Widget installed on the Terminal. The user is able to choose a list item for rendering by the WRE |
| Widget Manager |
The Widget Manager manages the life cycle of a Widget resource like Installation, De-installation and version update |
| Widget Processing |
Widget Processing involves the following steps:
- Acquire a Widget resource Over HTTP or Local storage
- Verify the zip archive and its file entries
- Locate the digital signature
- Process the digital signature
- Locate the configuration document
- Process the configuration document
- Instantiating the Start File
|
