Data objects

The data structures that will be shown thereinafter refer to fields of data packages, which are ultimately composed of arrays of binary codes. It must be clearly stated that an object of the Focus-n system is not directly related to an object of the object-oriented programming language, the latter being defined by its class (or prototype) and containing some fields of data and being associated to some methods for processing that data. Focus-n objects are essentially information containers, and the structure of such information is defined by the type of the object. Though, each object may well be implemented at run-time as an instance of a specific object-oriented class.

FIG. 3 shows the generic structure of System Objects 300 and User Objects 310. The invention separates these two kinds of objects, one for defining the system elements and another for defining the user data, because the system elements are less complex, for example, they do not have to include other (system or user) objects inside.

Both kinds of objects present the same two fields for identification purposes: the Object_ID field 320 is the unique number of the object for the corresponding type, which is defined by another unique number in the Type_ID field 325. This means that each type of the Focus-n system must have assigned a unique number, and that the numbers of the objects must be unique only within the group of object identifiers of the corresponding type. For example, it can exist a text object with Object_ID = 1 and an image object with Object_ID = 1, but it can not exist two text objects with Object_ID = 1. The numbers for Type_ID must be manually assigned by a centralized organization, to avoid conflicting numbers in types created by third-party programmers. As an ad hoc rule, the system types will have identification numbers below 1000, and the user types will have identification numbers above 1000. The numbers for Object_ID will be automatically assigned by the Type Manager as new objects are created. Therefore, each object in the inventive system is univocally identified by these two fields 320 and 325.

The Lang_ID field 330 is the numeric identifier of the language in which the textual fields of the object are written. This field allows to have several linguistic versions of the same object. For example, it can exist a text object with Object_ID = 1 and Type_ID = 1004, but written in two or more languages, which will generate two or more instances of the same object, e.g. with Lang_ID = 3 (English) and Lang_ID = 10 (German). This multiplicity of the same object (with the same Object_ID and Type_ID) is handled with the “Babel bubble” concept, which will be explained below.

But the language specification also applies to metadata fields, i.e. fields that contain attributes for describing the data of the object. Examples of metadata are the Name 360 and Description 365 fields of a system object, which will provide for a textual identification and description of the object for the user to recognize that object. Therefore, a system object can be described in several languages. For example, the types of the system are represented by system objects, hence the user may view the installed types by name (and description), and consequently the user may choose among the available languages for reading that list of types. Extending this capability to all system objects makes it possible to change the language of the whole user interface by means of a mere selection of the available Lang_ID values of the system objects.

The entry {other fields} 340 is a placeholder for other metadata attributes of the two kinds of objects, whereas the {information} placeholder 350 stands for the fields that actually contain the data of the object. For example, for an image object, the {information} may be the binary codes for the color of each pixel, and the {other fields} may be the size of the image, as well as a snapshot of the image. Another more generic metadata may be the number of references to the object, which indicates how many occurrences of the object there are within other objects.

The remaining specific fields for user objects are the Locator 370, used to identify the object from within other elements like sets or frames, and the Hierarchic frame 380, used to construct the “essential frame” of the object, i.e. the frame that holds the object itself, not within other objects. These concepts will be explained more deeply in next sections.