System and method for storing and managing information

Abstract

This invention is an information storage system which provides a self-contained environment for database management. Data are stored in the system not as conventional entries in memory locations, but instead as a group of connections between database sets. Procedures are also encoded as database set connections, and not in conventional form. Data and procedure cannot exist independently, in the present invention; instead, they are grouped together, into constructs called Contexts. Because the connections themselves are the data, the system is substantially independent of the particular hardware on which the system is implemented. The environment includes an editor which uses an icon-based syntax to create and manipulate data and procedure structures according to the invention. The present invention greatly reduces the time required to develop and maintain a database management system or other computer program. The system is not limited by the size of data variables. Also, a change in a data value, in one location, automatically changes that value throughout the system. Programs designed with the environment of the present invention are easier to code than conventional programs, and are generally self-documenting.

Claims

What is claimed is:

1. An information storage system which is connectable to an input interface means and an output interface means, the information storage system comprising a computer, the computer having a memory, the memory of the computer having a plurality of nodes stored therein, each node having a unique identifier within the memory, the memory of the computer including means defining pointers between pairs of said nodes, the pointers comprising only identifiers of other nodes, the pointers having been assigned by the input interface means in response to transmission of input data to the input interface means by a user, wherein each node contains no application data elements other than pointers, wherein information to be stored is stored only as a pattern of said pointers, and wherein said stored pattern is convertible by the output interface means into data recognizable by the user.

2. The system of claim 1, wherein the information being stored includes both data and procedure information, and wherein data and procedure are arranged in a structure called a Context, wherein every Context contains both data and procedure, and wherein all procedure information is stored in the same manner as any other information in the system.

3. The system of claim 2, wherein the system includes a set of pre-defined procedures, the predefined procedures including:

a) a Locate procedure for locating data within a data structure,

b) a Delete procedure for deleting data within a data structure,

c) a Precede procedure for adding data to a data structure,

d) an Iteration procedure for iteratively executing a portion of a procedure, and

e) an Enumeration procedure for executing one of a plurality of enumerated alternatives.

4. The system of claim 3, wherein the system further comprises:

a) an Invoke procedure, for executing a Context,

b) an Accept Argument procedure, for enabling a Context to receive data, and

c) a Return Argument procedure, for enabling a Context to transmit data to another Context.

5. The system of claim 2, wherein the information stored in the system is stored within a plurality of directories defined by a user.

6. The system of claim 2, wherein the computer itself comprises means defining said identifiers and said pointers.

7. The system of claim 2, wherein said pointers are created through a program operated by the computer.

8. The system of claim 2, wherein there are at least two Contexts, and wherein the computer includes at least two, processors, arranged to operate in parallel, and wherein different processors are assigned to execute different Contexts.

9. The system of claim 1, wherein the information is arranged in a plurality of boxes, wherein a box may be connected to other boxes, wherein a given box may be assigned one or more "child boxes", the computer being programmed to display the contents of a single given box, the computer being further programmed to display the child boxes of a given box, the computer being programmed to continue to display, when requested by a user, the child boxes, if any, of the box being currently displayed.

10. The system of claim 1, wherein wherein the information is arranged in a plurality of boxes, wherein a box may be connected to other boxes, wherein a given box may be assigned one or more "child boxes", said given box being called an "owner box", the computer being programmed to represent the boxes in outline format, wherein the child boxes of a given owner box are listed in an indented column relative to the owner box.

11. A method of storing information in a computer, the computer having a memory, the method comprising the steps of:

a) defining a plurality of nodes stored in the memory of the computer, each node having a unique identifier within the memory,

b) accepting at least one item of information from a user, and

c) storing within each node at least one pointer, each pointer comprising only an identifier of another node, wherein each node contains no application data elements other than said pointers,

wherein the information to be stored is stored only as a pattern of said pointers.

12. The method of claim 11, wherein the information being stored includes both data and procedure information, and wherein data and procedure are arranged in a structure called a Context, wherein every Context contains both data and procedure, and wherein all procedure information is stored in the same manner as any other information in the computer memory.

13. The method of claim 12, further comprising the step of providing a set of predefined procedures, the predefined procedures including:

a) a Locate procedure for locating data within a data structure,

b) a Delete procedure for deleting data within a data structure,

c) a Precede procedure for adding data to a data structure,

d) an Iteration procedure for iteratively executing a portion of a procedure, and

e) an Enumeration procedure for executing one of a plurality of enumerated alternatives.

14. The method of claim 12, wherein the information stored in the system is stored within a plurality of directories defined by a user.

15. The method of claim 12, wherein the computer intrinsically comprises means for performing the pointer storing step.

16. The method of claim 12, wherein the computer executes software which is loaded into the memory of the computer, the software comprising means for performing the step of storing the pointers.

17. The method of claim 12, wherein there are at least two Contexts, and wherein the computer includes at least two processors, arranged to operate in parallel, and wherein different processors are assigned to execute different Contexts.

18. The method of claim 11, wherein the information is arranged in a plurality of boxes, wherein a box may be connected to other boxes, wherein a given box may be assigned one or more "child boxes", the method further comprising the steps of displaying the contents of a single given box, upon request of a user, and displaying the child boxes of a given box, upon request of the user, and continuing to display, when requested by the user, the child boxes, if any, of the box being currently displayed.

19. The method of claim 11, wherein wherein the information is arranged in a plurality of boxes, wherein a box may be connected to other boxes, wherein a given box may be assigned one or more "child boxes", said given box being called an "owner box", the method further comprising the step of representing the boxes in outline format, wherein the child boxes of a given owner box are listed in an indented column relative to the owner box.

20. An interface device for storing information in a computer, the computer having a memory, the memory comprising a plurality of nodes, each node having a unique identifier within the memory, the interface device comprising means for receiving information from a user and means for storing information in the memory of the computer, the information storing means comprising means for converting information received from the user into a pattern of pointers stored in the memory, each pointer being stored in a node and comprising only the identifier of another node, wherein each node contains no application data elements other than pointers, wherein the information stored by the storing means is stored only as a pattern of said pointers.

21. An interface device for retrieving information stored in a computer, the computer having a memory, the memory comprising a plurality of nodes, each node having a unique identifier within the memory, the information being stored in the memory of the computer only as a pattern of pointers, each pointer being stored in a node and comprising only the identifier of another node, each node containing no application data elements other than pointers, the interface device comprising means for interpreting said pattern of pointers and for converting said pattern into information recognizable by a user.

Description

BACKGROUND OF THE INVENTION

This invention relates to the field of automated information storage and retrieval, and provides an integrated programming environment which enables data structures to be easily built, maintained, and used.

There are many disadvantages associated with conventional database management systems. Data values are typically limited in size by the size of arrays and storage locations. If a data value is too large, it may be truncated; if it is too small, space is wasted. Increasing the size of data values, or adding data values to a data record, within a large program, can be a major project.

Database management systems are programmed with particular hardware in mind, and many hardware-related decisions must be made in the definition of data. One of the purposes of the present invention is to reduce this hardware-dependence.

In the present invention, data are stored in a manner which does not depend on the particular hardware implementation. The system of the present invention does require a relatively few hardware dependent modules (such as a program to send information to and from a monitor), but in its underlying structure, it is substantially machine-independent. Data can be added and removed, without regard to the size of individual data fields. Thus, the present invention eliminates the need for much of the program maintenance that is needed with conventional programs.

The present invention also helps the user in designing and coding a large database management system. With the integrated environment of the invention, the user can see the structure of data and procedure, and can, in effect, program in a very high-level language. By nature, the language of the present invention tends to be self-documenting, making it easier to maintain and debug programs written with the present invention. Thus, the invention substantially reduces the costs and time required for developing and maintaining large programs.

SUMMARY OF THE INVENTION

In its most basic aspect, the present invention is an information storage system in which data are stored as database set connections, and not as conventional data. It is another basic feature of the present invention that, to every set of data, there must be associated at least one defined procedure for operating on the data.

According to the present invention, data are stored in the form of "trees", which connect a network of nodes, or "boxes", in various ways. It is the connections between the boxes that represent actual data, not the contents of the boxes themselves. Thus, in implementing the system of the present invention, each box is associated with an internal "pointer" which points to another box, to which the previous box is connected. In one simple example, one may have a box entitled "Name", and a set of connections between that box and a set of boxes each representing a different character. As long as the system knows which boxes are connected, how many connections exist, and the order of the connections, the data comprising the "name" are fully defined by the set of connections between boxes. Thus, the representation of data is essentially independent of the hardware used, and the data are inherently expandable by adding to the database set connections. Also, the connections need not be made between boxes; a "box" is used as a convenient icon in the preferred embodiment, but other icons can be used.

In the system of the present invention, boxes are connected to other boxes, which in turn are connected to further boxes. Because the structures used in the present invention are therefore inherently recursive, the system of the present invention can be described as "fractal". The term "fractal" is used as an analogy, in describing the information storage scheme of the present invention.

The same scheme is used to encode procedural instructions. Data and procedure can thus be represented by their own "trees". For each data structure, there must be an accompanying procedure structure, and vice versa. Data and procedure structures are grouped together into compound structures called Contexts. Contexts are analogous to conventional subroutines and co-routines, and permit the stored data to be used and manipulated.

The present invention also comprises an integrated environment for program design and execution. A primary feature of this environment is an editor program which enables the user to create boxes (or other icons) and connections, for both procedure and data. The programs generated in this environment are generally self-documenting, and are thus easy to design and maintain. All of the procedures possible with the program of the present invention are built of several basic "primitive" commands and procedures.

The "boxes" discussed above can be represented internally, within a computer memory, by discrete units called Bricks. Each Brick is essentially a memory location containing a set of pointers, each pointer pointing to some Brick. It is therefore a fundamental principle of the invention that all data and procedure is represented as a collection of pointers.

It is therefore an object of the present invention to provide an information storage and retrieval system.

It is another object to provide a database management system in which data are stored in a manner which is hardware-independent.

It is another object to provide a database management system in which the sizes of the data elements are not limited.

It is another object to provide an integrated programming environment for a database management system.

It is another object to provide a programming environment which greatly facilitates the design, development, and maintenance of large programs.

It is another object to provide a data storage system in which all data are stored in the form of connections, or "pointers", and not as conventional data.

It is another object to provide a system as described above, in which procedural instructions are also stored in the form of connections or "pointers".

Other objects and advantages of the present invention will be apparent to those skilled in the art, from a reading of the following brief description of the drawings, the detailed description of the invention, and the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1(a) through 1(c) are diagrams showing several successive stages of the growth of a fractal shape.

FIG. 2 is a diagram representing a sample record in a sequential file.

FIG. 3 is a diagram representing another sample record in a sequential file, and having truncated and missing values.

FIG. 4 is a diagram representing another sample record in a sequential file, but without missing or truncated data.

FIG. 5 is a diagram representing a sample record in a relational database file.

FIG. 6 is a diagram representing a sample record in a relational database file, showing truncation of some of the data.

FIG. 7 is a diagram representing a sample data structure in a fractal database.

FIG. 8 is a diagram showing another representation of the sample data structure of FIG. 7.

FIG. 9 is a diagram showing a sample procedure description for use with a fractal database.

FIG. 10 is a diagram showing a sample directory structure in a fractal database environment.

FIG. 11 is a diagram illustrating the portion of a sample data structure which shows that a child's sex is female.

FIG. 12 is a diagram illustrating all possible values for [Child's Sex], in the example of FIG. 11.

FIG. 13 is a diagram showing the representation of all possible values of a piece of data.

FIGS. 14(a) through 14(d) are diagrams showing a data definition and data value, both before and after execution of an assignment of a value to a data definition.

FIGS. 15(a) through 15(d) are diagrams showing a data definition and a data value, both before and after executing the command "Precede [Child's Name] with [A]".

FIGS. 16(a) through 16(d) are diagrams showing a data definition and data value, both before and after execution of three Precede commands.

FIG. 17 contains examples of data boxes.

FIG. 18 contains examples of procedure boxes.

FIG. 19 contains examples of directory boxes.

FIG. 20 contains examples of two different box name styles.

FIG. 21 is a diagram showing an example of a Synchronous Line.

FIG. 22 is a diagram showing an example of an Asynchronous Line.

FIG. 23 is a diagram showing an example of an Enumerative Line.

FIG. 24 is a diagram showing sample Synchronous Procedure Lines.

FIG. 25 is a diagram showing a sample Asynchronous Procedure Line.

FIG. 26 is a diagram showing sample Enumerative Procedure Lines.

FIG. 27 is a diagram illustrating the syntax for a sample iterative procedure.

FIG. 28 shows several sample Context Box names.

FIG. 29 shows a sample Context Name from the calling side.

FIG. 30 is a diagram showing a sample Context Argument Data Type.

FIG. 31 shows a sample Context name, from the called side.

FIG. 32 shows another example Context.

FIGS. 33(a) and 33(b) comprise a Chart showing the data structure for the sample Context of FIG. 32.

FIG. 34 is a Chart illustrating the calling of a Context.

FIG. 35 is a Chart showing two similar data structures.

FIG. 36 is a Chart showing sample Directory Boxes with associated Contexts.

FIG. 37 is a diagram of the Null Box, in two possible scenarios.

FIG. 38 is a diagram showing the two forms of the Locate Context.

FIG. 39 is a diagram showing the Data Chart for the Argument Box for the Locate Context shown in FIG. 38.

FIG. 40 is a diagram showing the usage of the Locate Context to find the first occurrence of a data value.

FIGS. 41(a) through 41(c) are diagrams showing the usage of the Locate Context to find the first value which matches a predetermined value, and includes data definitions.

FIG. 42 is a diagram showing the form of the pre-defined Precede Context.

FIG. 43 is a diagram showing the form of the pre-defined Delete Context.

FIG. 44 illustrates the pre-defined Iteration Context, using the format of a Context Box.

FIG. 45 is a sample Procedure Chart using the Iteration Context.

FIG. 46 is a sample Chart, similar to FIG. 45, but using the normal Iteration syntax.

FIG. 47 illustrates the pre-defined Enumeration Context, using the format of a Context Box.

FIG. 48 is a Chart which illustrates the internal representation of a sample Enumeration Context.

FIG. 49 is a Chart which illustrates the external representation of the Enumeration Context of FIG. 48.

FIG. 50 is a diagram showing the Context Box format for the predefined Invoke Context.

FIG. 51 is a Chart showing the external representation of the Invoke Context.

FIG. 52 is a Chart showing the internal representation of the Invoke Context.

FIGS. 53(a) and 53(b) are diagrams showing two callings of a Context which may or may not be the same.

FIG. 54 is a Chart showing a data structure using the same Data Box twice.

FIGS. 55(a) and 55(b) illustrate two Context Argument Boxes, to show how the system resolves ambiguities in Box names.

FIG. 56 illustrates the editor screen after the first Create Command, in a sample editing session.

FIG. 57 shows the editor screen after first Commit Command, in a sample editing session.

FIG. 58 shows the editor screen after a second Create Command, in a sample editing session.

FIG. 59 shows the editor screen after creating the Context described in the sample editing session.

FIG. 60 shows the editor screen after creating a Child Box called [Byte], in the sample editing session.

FIG. 61 shows the editor screen after completion of the definition of the Argument Box, in the sample editing session.

FIG. 62 shows the editor screen after execution of a Zoom In Command from open space, in the sample editing session.

FIG. 63 shows the editor screen with the Data Structure of the Argument Boxes, in the sample editing session.

FIGS. 64(a) and 64(b) show the structure of the procedure structure for a Context which performs a logical AND.

FIGS. 65(a) and 65(g) comprise a Chart showing the use of the present invention to maintain a list of telephone humors.

FIGS. 66(a) and 66(b) comprise a Chart showing a simple structure, and an accompanying diagram illustrating the Bricks comprising the structure.

FIGS. 67(a) and 67(b) comprise a Chart and diagram similar to FIG. 66, but wherein Box [C] of FIG. 66 has been replaced by Box [E].

FIGS. 68(a) and 68(b) comprise a Chart showing a data structure, and a diagram showing the representation of that structure as Bricks, illustrating the assignment of values to such structure.

FIG. 69 is a simple Chart showing the Procedure Structure which assigns a sample value to the structure of FIG. 68.

FIG. 70 is a diagram showing the Brick representation of a portion of the Data Structure of FIG. 68, before execution of the Procedure of FIG. 69.

FIG. 71 is a diagram showing the Brick representation illustrated in FIG. 70, after execution of the Procedure of FIG. 69.

FIG. 72 is a diagram showing the Brick representation of FIG. 71, after a second execution of the Procedure of FIG. 69.

FIG. 73 is a diagram showing the Brick representation of FIG. 70, after execution of the Procedure [Precede [Sex] with [Male]] and then [Precede [Sex] with [Female]].

FIG. 74 is a diagram showing the links in which each Brick may participate.

FIGS. 75 and is a diagram showing the physical layout of a Brick in memory, and showing the pointer usage for linking and tuning.

FIG. 76(a) and 76(b) show two portions of procedure Charts, illustrating the effect of removing an unnecessary Box.

FIG. 77 is a diagram showing a lexical representation of part of the Data Structure of FIG. 65.

DETAILED DESCRIPTION OF THE INVENTION

1. Introduction

The present invention is a software product which replaces virtually all of the tools commonly used to support program development and execution. The invention is entirely self-contained. It serves as a multitasking operating system, language compiler, database management system, linker, debugger, source code editor, file directory structure, screen handler, program documentation aid, and design tool. In the environment of the present invention, these components are tightly integrated into a single unit utilizing a single syntax.

In order to achieve this high degree of integration, the present invention employs a recursive structure to define programs and data rather than employing bits and bytes. This recursive structure is analogous to the geometric construction known as a "fractal". A fractal shape is drawn by replicating a simple curve many times over according to an algorithm. The drawings which result from this process often form intricate patterns which can closely resemble landscapes, clouds, snowflakes, stellar constellations, and other apparently random patterns. These techniques can also be successfully applied in the construction of information systems.

A simple fractal shape can be constructed with little difficulty. Only a curve and an algorithm are necessary for the construction process. For example, a curve which can be used to draw a sample fractal shape is a "+"-shaped line. The algorithm applied to this curve is to replace all straight lines with another "+"-shaped line. The diagrams in FIGS. 1(a) through 1(c) show a few iterations of the algorithm.

In an analogous manner, the present invention uses a recursive, or "fractal" technique for intricate representations of data structures. But rather than blindly replicating a curve according to a simple algorithm to produce a fractal shape, the invention selectively replicates linkages between database sets. The presence or absence of a certain part of the fractal shape represents the presence or absence of a particular data value. The present invention provides the analog of an algorithm and a fractal curve to model complex databases and systems. One such model of a database and system is the invention itself; excluding hardware device drivers, the present invention is written entirely in the language of the present invention.

The key concept of the present invention is its sameness. Because the invention is based on a single fractal "curve", all aspects of the environment of the invention become virtually identical. To match the underlying fractal nature of the present invention, a traditional lexical software environment with word-based syntax has been abandoned in favor of a graphic software environment with icon-based syntax. The present invention employs a compact, simple syntax, utilizing only eight pre-defined primitives built from four graphic symbols to completely describe any database relation, data value, program, directory structure, subroutine, or multitasking operation. This specific implementation of the environment of the present invention is only one of the many possible implementations of a fractal information system.

The environment of the present invention spans virtually all aspects of program development and database management, as well as some of the less-thought-of areas of data processing. As a working definition, the term "environment" refers to the collection of the following software components:

Multi-tasking operating system;

Stored database;

Executable procedures;

Database schema language;

Database schema language editor;

Database query language;

Database query language editor;

Procedural language;

Procedural language editor;

Screen generator;

System prototype generator;

Database maintenance utilities;

Source code maintenance utilities;

Hierarchical directory structure;

Symbolic Debugger;

Computer Aided Software Engineering (CASE);

and the following hardware components:

The "fetch/execute" procedure-execution hardware;

Physical storage media, such as a 32-bit.times.256K-byte core memory;

Hard-wired Arithmetic/logical operations, such as "Multiply" or "AND";

and the following system development components:

Structured analysis;

Structured design;

Data encapsulation;

Object oriented;

System development methodology;

Self-documentation.

and the following general design goals:

Simplicity;

Fast to learn;

Consistency;

Easy to change;

Infinitely expandable in all aspects.

Since any hardware components can be simulated by software components, the term "software component" may include all hardware components. Also, a new form of hardware can be tailored to match the fractal environment.

The present invention significantly reduces the cost of developing and maintaining information systems. Such systems have been developed with the present invention, and the result is substantial savings in the area of time efficiency, design efficiency, and maintenance efficiency.

The most striking benefit of the environment of the present invention is the reduced amount of time required to bring an application online. Systems implemented in the present invention required a maximum of one-fourth (1/4) to a minimum of one-thirtieth (1/30) of the time required by the traditional programming approach, with the average application requiring approximately one-tenth (1/10) of the usual time.

Another benefit of the environment of the present invention is in enhanced design efficiency. Although most programmers routinely perform some level of design activity before beginning coding, only a few design the entire system. Some perform no design at all. Coding in the present invention, however, is the virtual equivalent of designing with state-of-the-art design tools, but with the added value of total system integration stemming from the fractal viewpoint. This yields better, more straightforward, easily maintainable designs.

The environment of the present invention also provides for the online maintenance of all data and programs. Because of the simple internal structures of the present invention, adding or removing peripheral devices or additional disk or memory can be performed online while other programs in the system are still executing. This simple Reduced Instruction Set Software (RISS) architecture also limits the number of things that can go wrong in a system. Except for hardware failures, there are virtually no error conditions possible within the environment of the present invention. This simplifies coding and greatly reduces overall maintenance efforts.

Unlike programming tools of the prior art, the present invention is completely hardware-independent. The separation of the underlying machine from the data structures is a complete one in that no hardware-related decisions are involved in the definition of data. This one fact greatly reduces maintenance needs over the long term. Because all data values in the present invention are of variable length and infinitely expandable, data values can be built of as many digits or characters (or whatever) that they need to be. This reduces the maintenance effort because many problems will never appear. For example, truncating data values or overflowing arrays simply cannot happen. Having to expand fields to accommodate larger numbers need never be performed. A byte can have as many bits as needed, irrespective of the underlying hardware. Additionally, due to the complete lack of duplication of data in the present invention, changing a data value in one place instantly changes all occurrences of that value, systemwide and simultaneously. Thus, most of the maintenance problems inherent in traditional systems have no counterpart in the present invention.

In the present specification, particular terms of importance to the present invention are capitalized.

2. Fractal Database Theory

To understand the fractal information system of the present invention, it is helpful to describe and compare the methods of storing information in sequential, relational, and fractal environments, respectively. The following examples describe a generalized implementation of the data structure required to represent the information "parent's name", "parent's sex", "children's names" and "children's sex".

2.1 Sequential Information Systems

The first type of information system to be reviewed is the sequential information system. A sequential information system holds all data in lists. To access a particular entry in a list, either the list is scanned sequentially, or some form of indexing is employed.

A sequential information system is modeled very closely on the underlying hardware devices, such as core memory, tape drives and disk files. The reason for this approach is that historically, storage was at a premium. The high cost of hardware prohibited any unnecessary overhead. Thus, virtually all of the information that was kept in storage was the actual data value. This philosophy of data storage persists in many (if not most) sequential file systems today. For example, no information is generally included with a data record which associates any single record with any other record. This association is usually performed by the physical sequencing of the data records themselves. This lack of explicit control information is one of the primary indicators of a sequential system.

For example, implementing the sample data structure "parent's name", "parent's sex", "children's names" and "children's sex" can be accomplished in a sequential information system with the universally-implemented fixed-length record. A fixed-length record usually includes space for only a finite number of fields due to hardware or software limitations. To keep the examples simple, assume that the hardware can accommodate a record length of only a few dozen bytes, rather than the usual, less-restrictive 32,767 bytes.

FIG. 2 is a pictorial representation of a sample record format representing the information "parent's name", "parent's sex", "children's names" and "children's sex" in a sequential file. In this flat file structure, no interrecord information is retained to connect two records, except for the record sequencing itself. This sequence is usually enforced by the storage media.

Many difficulties arise with the use of sequential files. For example, information on a given child could possibly appear more than once within the information storage system. Also, because of the fixed format, a name can be truncated or a third child could be omitted. FIG. 3 illustrates these points for the case of John and Mary Smith and their three children Ada, Kareem Abdul, and Ralph. Notice that in FIG. 3, Kareem Abdul's name is truncated and Ralph's was omitted entirely. Conversely, the spaces which follow most of the names represents unused, wasted space.

There are various methods available to circumvent some of these problems, but such methods are generally rather inefficient. A few of these tuning measures are listed below:

Field sized can be fine-tuned to minimize truncation of names. However, this requires an extensive analysis effort and the analysis must be periodically reviewed.

The codes "M" and "F" can be introduced to signify Male and Female, respectively, to reclaim additional space. But the encoding/decoding of any sort of code involves processing overhead as well as adding complexity.

A second record could be added to show the existence of more than two children, but only at the expense of 1) duplicating the parent's name on the new record; and 2) incurring the processing overhead required to handle the multiple-record case.

Once the above procedures are performed, the result begins to appear less like real information and more like common programming practices. FIG. 4 shows both the tuning of field sizes and the addition of a second record which includes the missing child's name.

Still another level of tuning can be introduced. Rather than duplicating the parent's name or child's name, a code can be used instead of the name, such as an individual identity number or some other value. Regardless of the encoding of this key information, one of the drawbacks of a sequential information system is that some piece of programmer-maintained data must be duplicated to serve as that control information, whether it is a name, a social security number, or whatever. This duplication of data now introduces an additional problem: when a name or code is changed, all occurrences on all records must be changed as well. The overhead incurred in altering every occurrence of a given value is not trivial.

Placing the burden on the programmer to process the above-described implied control information increases the complexity of any program. In other words, whenever a module is written which matches up two records, the programmer is, in effect, writing a relational database handler to extract and utilize the control information hidden in the records or in their sequencing. This means that the control information which links two records together is represented as executable code rather than as stored data. This requires that the actual linking be performed again each time the program is executed, which is clearly a waste of hardware resources.

Thus, sequential information systems are inefficient in the storage and extraction of information. Although the inefficiencies can be minimized somewhat, they remain formidable.

2.2 Relational Information Systems

The second type of information system to be discussed is the relational information system. In a relational information system, data is still stored in lists, as in the sequential information system. However, rather than storing all of the information in one large list and its related record-matching programs, the information is scattered in several smaller lists. These small lists are joined, not by their relative sequence or by record-matching programs, but by control information introduced by the relational information system itself.

The sample data structure of parents and children discussed above is represented in a somewhat different manner by a relational information system than by a sequential system. The primary difference is that in the relational system, the children's names and sexes are stored independent of the parent's names and sexes. The relational system adds the necessary control information which can link parents to children, namely, a "Parent-Child" database set. Generally, these relationships can be shown as illustrated in FIG. 5.

Storing the child information in separate lists eliminates much of the chance for duplication that occurs within a sequential information system. Nevertheless, duplication still exists, but now on a different level. A given name (such as "John Smith") or a given sex (such as "Female") could possibly appear more than once within the smaller lists. On yet another level, the individual text characters which comprise a given name or sex are continually being duplicated in that they can occur multiple times within a list or across many lists. (This implies that converting a database from EBCDIC to ASCII is, by design, a byte-by-byte effort). Also, the possibility for truncation still exists.

FIG. 6 shows the result of some of these deficiencies for the case of John and Mary Smith and their three children Ada, Kareem Abdul, and Ralph. Note that all of the problems encountered in sequential information systems are evident here as well. For example, Kareem Abdul's name is still subject to possible truncation; note also that the spaces which follow each of the names still represent unused, wasted space. To circumvent or minimize these problems, the same tactics which were used in the sequential information system can be used here as well. Codes can be introduced and space apportionment can be tuned, but only with the attendant cost of increased effort and complexity.

Despite these shortcomings, the relational information system has many advantages over the sequential system, including reduced duplication with the resultant improvement in processing efficiency. However, duplication of information still occurs. Control information must still be implied by the programmer when the code is required to "walk" through two or more database sets to collect all of the needed data. Requiring each program to walk these sets introduces a maintenance problem: should the database set connections change, any program which traverses those sets must also be changed, requiring a non-trivial conversion effort. Thus, relational information systems are inefficient in the storage, maintenance, and extraction of information, but not as inefficient as sequential information systems. Although the inefficiencies can be minimized somewhat, they still remain formidable.

2.3 Fractal Information Systems

The third type of information system, and the one used in the present invention, is a fractal information system. This type of information system is discussed below.

"2.3.1 Selecting the Fractal "Curve"

To understand the structure of a fractal information system, consider the differences between the sequential and relational systems. In a sequential information system, data is stored in one big list. There are no links between records except for media-induced links (i.e., the fact that the information is kept as adjacent ASCII bytes) and programmer-induced links (i.e., the fact that a program performs record matching). A relational system links various smaller lists together, replacing some of the media- and programmer-induced links with system-induced links (i.e., belonging to the "Parent-Child" database set). However, the relational system does not replace all of the links. Hardware dependencies still remain.

A fractal system continues this replacement of media- and programmer-induced links with system-induced links until all media- and programmer-induced links are gone. With the removal of the media-induced links, all hardware dependencies are removed as well. With the removal of the programmer-induced links, programs become simpler to write and maintain.

An example of this kind of link replacement can be performed with "parent's name" from the sample data structure. In the sequential and relational systems, the characters in the parent's name are linked together by the storage media, that is, the characters reside in adjacent bytes. In a fractal information system, this media-induced link is replaced with a system-induced link. Specifically, a "Name-Letter" database set is introduced. This replaces the media-induced adjacency of the ASCII characters in the parent's name with system-induced links instead. Just as a parent can have certain children, a parent's name can have certain letters. If system-induced links can be used to connect a parent to the children of that parent, they also can be used to connect a name to the letters of that name.

Thus, in a fractal environment, the name is not a collection of adjacent ASCII bytes. Rather, each byte in the name is stored a member of the "Name-Letter" database set. For the parent "John Smith", for example, the first member in that "Name-Letter" set is "J", the second member is "o", the third, "h", and so on. Note that the letter "h" participates twice in the "Name-Letter" database set for "John Smith": initially as the third member in the set representing the name "John Smith", then again as the last member.

The ability to link each individual letter to a character string implies certain changes in the manner of storing data. The most significant change is that each letter must be stored separately in the information system so that it can be linked separately. Thus, each letter becomes the only value in its respective list. In this way, a given letter (that is, its single-letter list) can be linked as a member of many different "Name-Letter" sets to form many different parent's names. But the actual letter itself need only appear once within the entire information system, specifically, as the only member in its list.

A unique ability of a fractal system is based in the concept of a single-letter list. Since a given letter is stored in only one list within the entire information system, the letter can be changed to any other letter at any time; simply change that single value in that list. Because it is the only copy of the letter within the entire system, the change would apply to all usages within all sets instantaneously, simultaneously, and systemwide.

Despite the fact that a particular letter is not often changed, the ability to do so reflects a powerful aspect of fractal systems. Any database set connection can be altered in this manner. This feature drastically simplifies the maintenance overhead of changing all occurrences of a given value, as well as simplifying the general problem of sharing data online.

Introduction of the "Name-Letter" database set has a major duplication-limiting effect on the storage of the characters. This is shown in the relationship between the name "John Smith" and the letter "h" which is used twice in the name. For example, for each usage of the letter "h", the "h" list is linked as a member of the "Name-Letter" database set. Remember that the letter "h" is not an ASCII character; it is the only value that is stored in the "h" list. This "h" list is connected as a member of the "John Smith" "Name-Letter" database set two separate times. Even though there is only one "h" which occurs in the "h" list, it is linked into the "John Smith" name twice rather than being duplicated in the name. That single copy of the letter "h" may be linked elsewhere, participating in many other sets throughout the information system. Just as two parents can share the same child, two or more names can share the same letter " h". That letter "h" is stored in one and only one list within the entire information system rather than being duplicated in other lists with other letters. Names which need this letter must link on to it via the "Name-Letter" database set. Thus, with the introduction of the "Name-Letter" database set, a media-induced link is replaced with a system-induced link.

However, there is another externally-induced link which still exists, but a much subtler one. An example of this subtle link is the link between the "h" list and the letter "h" itself. It is important to note that the letter "h" is unique within its list, being the only member. One may therefore replace the link between the list and its letter with a database set connection, namely a "Letter-h" database set. Thus, the "Letter-h" database set can be linked instead of the actual letter "h". This implies that the actual encoding of the letter "h" need not physically exist; it can be replaced with a database link instead. Thus, a fractal system can utilize any letter in the name without resorting to any hardware-related information (such as the ASCII code of the letter). The ASCII value of each letter is replaced internally with a database set.

Thus, in order to represent the value for the name "John Smith", the name can be linked to its letters via the "Name-Letter" database set, which in turn can be linked to its specific value through the "Letter-J" set, the "Letter-o" set, the "Letter-h" set etc. The actual letter "h" is no longer needed because the presence of the letter "h" in a name can be established simply by knowing that this particular letter in the "Name-Letter" set is a member of the "Letter-h" database set. Because it is in the "Letter-h" set, it must be the letter "h" and nothing else. Since the value can be determined from the set name, no actual encoding of the letter "h" is required to physically exist. It is enough to know that this member is of the "Letter-h" database set to know that it is indeed "h".

Thus, the lowest-level piece of information can be represented, not as an ASCII byte stored away in some list, but rather as a database set connection. It is thus a basic principle of the present invention that any information system can be represented solely by database connections. When all control information has been isolated in an information system, no explicit data values remain; only the control information of the database set connections remain.

Therefore, the database connection is the pattern, analogous to the fractal curve, which determines the "shape" of the environment of the present invention. The fractal "shapes" of the present invention are formed exclusively of database connections. These database connections connect other database connections with the connecting being performed by database connections.

Because any data can be expressed as only database connections, it is possible to construct a network of such connections which represent definitions of data and, by extension, definitions of executable programs. Thus, total hardware independence is achieved in a fractal environment. Any data can be represented as a series of database connections instead of a series of bits, bytes, or registers. Data is completely independent of the underlying machine environment, irrespective of the number of bits in a counter or the number of characters in a name.

To improve processing efficiency, hardware memory can be devised which is specifically designed to hold a representation of the database set connections. Hardware processor logic can access this "fractal" memory device, following the directions contained in the pattern (program) therein in order to change the pattern (data) therein.

Thus, fractal information systems do not use any lists at all. The list-induced duplication contained within the sequential and relational information systems is eliminated completely. All control information is moved out of the executable program and into the information system. This implies that changes to the data structure require no changes to the executable program.

2.3.2 Fractal Control Primitives

Having defined the structure of the data in a fractal database, the next step is to define those procedural elements which operate on that database.

Because, in a fractal environment, an information system can be built out of database connections, the process of choosing primitive procedure functions is greatly simplified. Because all data is represented exclusively as database connections, accessing all data in a fractal database is accomplished exclusively through database commands.

By using database commands, letters and numbers are manipulated as members of database sets rather than as binary encodings or arrays. Because a database set can be designed such that it can always hold another member, this database viewpoint provides for the infinite expandability of any data value. This permits the handling of both character and numeric values of any length. For example, there can be virtually an infinite number of members of a set, sets of sets, sets of sets of sets, etc. limited only by the amount of hardware available.

Within a fractal environment, procedural commands fall into two broad categories: database control commands and procedure control commands. These are explained below.

2.3.2.1 Database Control Commands

Database control commands are the most primitive functions which can act upon the contents of a database. In a fractal environment, there are only a limited number of functions which can be performed on the database due to the exclusive use of database connections for data definition. Since every connection in a fractal information system is, by definition, a database set, only a small group of database control commands need to exist. Specifically, these control commands are the basic database set operations. In general, the basic database set operations which can be performed on database sets are: locating, accessing, adding, changing or deleting data. Any other database operations can be constructed from these operations. However, even as many as these five are not absolutely required.

The following is an explanation of each of the above-mentioned database set operations.

2.3.2.1.1 Locating Data

Locating data means to find a certain entry in a database. Locating data can be positional, as in locating the first, last, next, or previous entry, or locating data can be direct, as in locating the entry which corresponds to a certain value. In either case, the located data value is made ready for accessing, i.e., it becomes the "current" value. Locating a value is a necessary prerequisite to pinpoint the target location in the database before any other database commands can be used.

2.3.2.1.2 Accessing Data

Accessing data means to extract the current value from a located entry. Since the only accessing that can be done to the database is via database commands, that is, through locating, adding, changing, or deleting, the term "accessing" is implicit in the other database commands, and, therefore, meaningless as an independent entity. This function can be omitted.

2.3.2.1.3 Adding Data

Adding data means to precede or follow the current entry with a new entry. The added entry becomes the current entry. Since "follow" means the same as "locate next" plus "precede", only "precede" is needed to add data; "follow" can be omitted. The precede function serves as the inverse of the delete function; it is required to increase the size of a fractal information system.

2.3.2.1.4 Deleting Data

Deleting data means to remove the entry from the database. The entry following the deleted entry becomes the new current entry. This function serves as the inverse of the precede function; it is required to shrink a fractal database.

2.3.2.1.5 Changing Data

Changing data means to replace the current entry with a new entry. Since "change" can be performed by "delete" followed by "precede", "change" does not need to exist explicitly. This function can be omitted.

One may include "change" instead of "delete" since deleting is the same as changing to a null value. It turns out that in the actual environment of the present invention, it makes no real difference; either one can be implemented. Additionally, the change can be made with no impact on any pre-existing data or procedures. With no reason to prefer "delete" to "change" the final decision can be deferred until hardware design. The remainder of this description assumes the existence of "delete".

In summary, only three database set operations, not five, are required to be defined as procedural primitives to perform all possible actions on a fractal database. These three database set operations are Locate, Precede, and Delete.

2.3.2.2 Procedure Control Commands

Procedure control commands are those commands which are required to automate the interaction between a human or machine and a database. If automated database accessing were not needed, no program control commands would need to exist; the human could directly access whatever data was required by using the database set commands alone.

Automating database accessing can be easily accomplished. There are only five situations which require any control. Hence, there are only five commands.

The first command, Invoke, initiates the execution of a program. The second, Iterate, gives the ability to step through all occurrences of a value, (such as looping through all characters in a name). The third command, Enumerate, controls choosing a course of action based on a data value (such as processing only female children). The fourth and fifth commands, Accept Argument and Return Argument, control the passing of data into and out of a given Procedure. These commands are more properly classified as pre-defined Procedures, and are therefore described later.

No actions, other than those described above, are needed to control an executing program. The first three of the above functions are described below.

2.3.2.2.1 Invoke Command

This command is used to initiate the execution of a procedure. Once Invoked, a process continues until completed. The Invoke command does not affect the issuing procedure, that is, the invoked procedure continues its execution independent of the issuing procedure.

2.3.2.2.2 Iteration Command

Iteration is the decision of when to abort the repeated executions of a function, depending on some database condition. For example, when copying a name, the function being done is to copy the next character. The database condition which aborts the character copy is the "end of set" condition which is found at the end of the name. Another term for Iteration is abort on condition; the character copy is aborted at the end of the set.

2.3.2.2.3 Enumeration Command

Enumeration chooses the path to take when multiple choices are available. For example, different processing choices are associated with early, on-time, and late employees. Depending on a database condition, only one of the three choices is processed for a given employee. Another term for Enumeration is "execute only one choice and abort". A late employee is only subjected to late processing; early and on-time processing are bypassed.

Iteration and Enumeration are closely related, but in a logically inverted sense. Where Enumeration performs a process (based on a true database condition) before aborting, Iteration performs no process (based on a true database condition) before aborting. Conversely, where Enumeration performs no process (based on a false database condition) before aborting, Iteration performs a process (based on a false database condition) before aborting.

Together, the eight commands described or mentioned above, namely, Locate, Precede, Delete, Invoke, Iterate, Enumerate, Accept Argument, and Return Argument form the complete set of program control commands necessary to manipulate data in a fractal environment. All other data processing operations, whether implemented in hardware (such as multiply) or in software (such as inventory control systems) can be built from these eight primitives. Of course, implementing a fractal system on non-fractal hardware introduces additional device-specific primitives which are associated with that particular device. Fractal hardware, however, requires only these eight procedural primitives.

2.4 Application of the Theory

The following discussion provides an informal model of a programming environment utilizing fractal concepts.

2.4.1 Fractal Data Descriptions

The central concept of a fractal environment is that any data can be represented solely by database set connections. The representation of these connections can take on many forms. The traditional "control card" approach can be implemented, or the latest formatted screen generator can be adapted to model the database connections. Rather than using a word-based or field-based syntax, a graphic-based approach can be chosen to represent the database connections.

Since there is only one possible element in a fractal environment, only one icon is needed to represent information structures. To keep the drawings simple, the presence of a database connection is graphically represented by a single vertical line. Another icon can be chosen, but a line is more straightforward. Since database connections simply connect to other database connections, these lines would only connect to other lines. For example, the icons for the sample data structure "parent's name", "parent's sex", "children's names" and "children's sex" could appear as shown in FIG. 7.

To keep the example simple, the representation for Mr. Smith and only one child, Ada, is shown. Also, to make this diagram more readable, two substitutions have occurred, marked by "*" and "#":

The "*" means that there are ten lines descending from this line. Each of those individual lines represent one of the characters in the Parent's Name, "John Smith".

The "#" indicates that there are three lines descending from this one line, one for each letter in the Child's Name "Ada".

FIG. 7 is an example of how to picture a data value (in this case for John Smith the Male and his Female daughter Ada) using a single type of icon with some comments written alongside of the icons. Note that it is the database connections which define the entire value.

Since the lines all look alike, the comments and icons together are necessary to give the human a complete understanding of the data value. Internally, of course, there is no ambiguity; each line represents a different database connection. Thus, it is necessary for the programmer's sake to include the comments along with the icons.

Including the comments along with the line can be effected in two ways. One cumbersome way is to make each line unique such that its uniqueness identifies the comment. While this approach is adequate for the internal hardware, a programmer requires a more practical solution to retain the simplicity of the fractal approach.

A less cumbersome way to associate comments with icons is to enclose the comments in a rectangle, hooking them on to the bottom of their respective lines, such as in the example shown in FIG. 8. FIG. 8 shows that the Sample contains two pieces: the Parent's Information and the Child's Information. Furthermore, it shows that the Parent's Information is comprised of the Parent's Name and Sex and the Child's Information is comprised of the Child's Name and Sex. Finally, the example shows the members which comprise the set that defines the Parent's Name, namely, the characters "J", "o", "h", "n", " ", "S", "m", "i, "t", and "h", and, for the Child's Name, the characters "A", "d", and "a".

In the example of FIG. 8, the fractal nature of the structure is clear. The fractal "curve" being replicated is the database set connection, represented by a near-vertical line with a box at the bottom; the algorithm which, by repetition, builds the fractal shape is the question, "What are the components of this data element?".

In the following description, brackets are used to indicate that the text contained within the brackets is contained within a rectangle. Thus, the rectangle with the word "Sample" within it is represented as [Sample] when used within a paragraph.

Iterations of the algorithm which creates the "fractal" structure of FIG. 8 cause the data structure called [Sample], in FIG. 8, to be divided into two components, namely [Parent Info] and [Child Info]. Using the same algorithm on [Parent Info] and [Child Info], [Parent Info] breaks down into [Name] and [Sex]; [Child info] breaks down in the same way. Applying the algorithm to [Name] shows that [Name] is composed ten characters. [Sex] can be either [Male] or [Female].

Applying the algorithm again to each letter reveals that there are no two meaningful components in the letter [J]. Because there is no further information about the letter beyond the [J], the construction of the fractal representation can halt at this point. [Male] and [Female] are not subject to further reduction either. Fractal construction can halt here, as well.

Note that all of the information represented in FIG. 8 is shown not by binary encodings, abbreviations, or ASCII bytes, but strictly through database connections.

Although there is some text associated with each database set connection (i.e., with each line), this text is not required to be present to represent the structure. When implemented on real machines, the set connections do not require the human-readable names; they can be assigned unique binary (trinary, decimal, or whatever) values which are of significance to the host hardware. As long as the hardware has a means of differentiating between lines, the text associated with the line is purely a comment for the human programmer's convenience. Because of this fact, anything, from text to graphics to spreadsheets, can be used to name the connection.

2.4.2 Fractal Procedure Descriptions

The system of the present invention uses the fractal analogy to define not only data structures, but procedure structures also.

In traditional procedure control systems, control is transferred among procedure components in many differing ways: by performing a subroutine call, by adding an increment to a memory pointer to locate the next instruction, by replacing that memory pointer with a new pointer, by generating a software interrupt or monitor call, or by another obscure, hardware-specific method.

In a fractal procedure, there is only one way to transfer control between procedures, namely, through a defined database set connection. Just as a data element can be broken down into several components, a given process or procedure can be broken down into several subprocesses which, when taken together, comprise the given process.

For example, the process "Print Page" can be divided into three subprocesses: "Print Header", "Print Lines", and "Print Trailer". By extrapolating from the form of a fractal data definition, the fractal description of this procedure can be constructed as shown in FIG. 9.

Note the similarity of form between a data definition and a procedure definition. This similarity is brought about by applying the same algorithm to procedure which was applied to data. When defining data, the algorithm applied is "What are the components of this data element?". When defining procedure, the algorithm is slightly modified to become "What are the components of this procedure element?" Because of this similarity, two procedural subprocesses which are components of a given process can be represented in the same manner as two data subfields which are components of a given field.

Executing a fractal procedure is accomplished by "walking" the lines in hierarchical sequence. The execution sequence for the example presented in FIG. 9 can be paraphrased as follows: [Print Page] is performed by invoking [Print Header] first, [Print Lines] next, and [Print Trailer] last. The sample does not show that [Print Header] has subordinates which, when taken together, print the header. Likewise for [Print Lines] and [Print Trailer]; all subordinates are traversed.

2.4.3 Integrating Procedure and Data

With the definition of both data and procedure descriptions completed, the next step is to define their integration.

In a traditional programming environment, a program is composed of four parts: a name (to identify the program), a process (to translate inputs into outputs), a local data area (to hold any intermediate results while translating inputs into outputs) and an interface to the program (a definition of its inputs and outputs). In other words, a name indicates a specific process which is accompanied by its data area, consuming inputs and producing outputs.

In a fractal environment, too, this definition is still a valid one. The combination of a name, a data area, a process, and its interface is called a Context. A Context is the named integration of a procedure with the data that it acts upon, accepting inputs and returning outputs. A Context is invoked by its Context Name either by a human or by another Context. When invoked, the named Context performs the Context process on the Context Arguments (transforming the Context input into Context out-put), using the Context Data to hold any intermediate results.

From a traditional point of view, the structure which most closely approximates a Context is a procedure block or a subroutine. A Context is similar to these structures in many ways: it can perform a discrete function, it can accept and return arguments, it can possess data values which are (or are not) retained across successive invocations, etc. A Context differs from a subroutine in that it is more independent than a subroutine; a Context is more like a stand-alone subsystem than a subroutine.

The most significant feature of Contexts is their ability to completely encapsulate the data associated with them. Encapsulation means that the data within a Context can only be accessed by invoking a process which is directly associated with that data (i.e., the Context procedure). Conversely, data cannot exist without the process required to service it. Data requires procedure and procedure requires data; one is meaningless without the other.

The latter statement implies that the traditional concept of a "file", that is, data without process, has no counterpart in the "fractal" environment of the present invention. If any data are to be stored, there must be some process to accompany those data which "knows" how the data can be accessed or manipulated. For example, if a Context encapsulates a list of children, the appropriate process must accompany that list to perform actions on the members of the list, such as adding, changing, or deleting children.

Thus, a Context is the named association of two fractal "shapes": the first "shape" is the fractal data structure, and the second shape is the fractal procedure structure which services that data structure. A Context is invoked by either a human or by another Context. A Context can accept inputs, return outputs, invoke other Contexts, and can access only those data associated with it.

2.4.4 Directories

The following is a description of the concept of Directories, which are the named locations of stored Contexts.

In a fractal environment, data and their associated procedure are joined together into Contexts. Because a Context is a combination of two fractal "shapes", the Context itself is a fractal "shape", capable of being represented solely as a database connection. Because it is a collection of database set connections, each Context can be treated in the same manner as any other data structure. Thus, a data structure can be built which groups Contexts together into meaningful subgroups. These subgroups are referred to as Directories.

A Directory is actually a Context which has no arguments; it exists to serve as a repository for other Contexts. Related Contexts can be associated with one another by being grouped within a Directory. For example, FIG. 10 diagrams the fractal shape of some possible Directories with some associated Contexts.

FIG. 10 shows how Contexts can be grouped together into various Directories. Directories can be introduced into the structure at any level, at any time, and to any depth.

There are a few difference between fractal-based Directories and the directory structures provided with PC-DOS, Honeywell GCOS, VM minidisks, etc. Fractal Directories can contain any other fractal "curves", such as other Directories or Contexts. Fragments of various structures can be grouped into Directories, such as segments of incomplete coding or other random items. Another significant difference is that a given Context or Directory can appear in more than one Directory, if necessary.

Directories are the glue which pulls the entire fractal environment together into a single, integrated whole. For example, tracing upward through any hierarchy of database set connections leads upward from the data or procedure database connections, up above the Context, up to the Directory. Tracing upward further through all directories, the ultimate database connection is reached: the Top Box. The Top Box is the root database set connection. From this one connection, everything in the entire fractal environment can be located, including any and all Directories, Context procedures, and Context data. All other database connections are either directly or indirectly associated with the Top Box.

All Directories are subdirectories of the Top Box, either directly as a subdirectory of the Top Directory, or as a subdirectory of some other subdirectory. All Contexts in a fractal environment are connected to at least one Directory. Subsequently, all data and procedure values are connected to their Contexts. Thus, Directory, Context, Procedure, and Data are all joined together into one single integrated fractal "shape", beginning at the Top directory and continuing uninterrupted down to the lowest-level data values.

2.4.5 Definitions versus Values

For a complete understanding of a fractal environment, one must understand the relationship between definitions and their values. The following section describes the differences between definitions and values, and describes them for both data and procedure structures.

2.4.5.1 Data Definitions versus Data Values

In a traditional programming environment, data receive values by means of some sort of an assignment, such as in the statement "Move 1 to Digit". Such an assignment implies two facts: first, that there is a chunk of storage defined by the name "Digit", and second, that there exists a value of "1" which is to be associated with "Digit".

In a fractal environment, too, there is a distinction between a data definition and its value. However, this distinction is a much subtler one. When a value is associated with a definition (via the Precede database command), that association is performed by a database set connection, rather than moving the value "1" from one location to another. Instead of being copied, the value "1" is only linked with "Digit" to serve as its value.

FIG. 11 replicates a portion of the sample data structure from FIG. 8, specifically, the portion which describes the child's sex as female.

While FIG. 11 clearly states what the value of [Child's Sex] is, it does not state what all of the possible values for [Child's Sex] might be. The value is there; the definition is not.

The information which is missing here is the complete definition of [Child's Sex]. Just as the statement "Move 1 to Digit" implies something about the definition of "Digit", so too does [Female] imply something about the complete definition of [Child's Sex], namely, that [Female] is one of its possible values, and that they are both the same data type. A complete definition would include all possible values.

This is the primary distinction between the definition of data and the value of that data. The definition describes all possible values for the data, while the value of the data only selects one specific choice from among all of the possible choices.

Applying this rule to the definition of [Child's Sex], all possible values consist of only three choices: [Female], [Male], or no value (i.e., null). Since the null value means that there is no connection to any other line, this choice is not included when drawing a structure. Thus, a fractal representation of the definition of [Child's Sex] can be drawn as shown in FIG. 12.

This style of notation introduces a minor inconsistency between the interpretation of a data definition and the interpretation of a data value: since the data value in FIG. 8 states that [Child's Name] is composed of [A] and [d] and [a], then by analogy, FIG. 12 states that [Child's Sex] is composed of [Female] and [Male], rather than [Female] or [Male]. Clearly, this does not portray the intended meaning.

To avoid ambiguity and circumvent this inconsistency, the relative meaning of a database set connection must be perceived differently.

Note that the inconsistency occurs only at the lowest level of a data structure. On any higher levels in the structure shown in FIG. 8, (for example, with [Child Info]), the inconsistency does not exist; [Child Info] does indeed consist of both [Child's Name] and [Child's Sex].

Thus, only at the lowest levels of a fractal shape does this inconsistency occur. Therefore, only at the edge of the fractal shape is there a differing interpretation of the meaning of a database set connection.

An example of this re-interpretation can be seen with [Child's Sex]. Because [Child's Sex] is at the lowest level of the fractal "shape", the "shape" is interpreted to mean that [Child's Sex] can be [Female] or [Male] rather than [Female] and [Male]. This alteration of interpretation is valid for the lowest-level data only.

For the sake of visual clarity, for the convenience of the human operator, the lowest level data can be represented differently in order to highlight this change in interpretation, even though the database set connection that it represents is in no way different from any other one in the entire environment. One possible representation of that reinterpretation is shown in FIG. 13.

FIG. 13 shows the possible values for [Child's Sex], namely, [Male], [Female], and nothing else.

It is important to note that no change has been made to the existing fractal "shape"; no "second shape" is being added to describe the different interpretation. Instead, for the definition of data, the edges of the fractal "shape" are treated as the set of possible values rather than as a definition.

The relationship between a data definition and its value can be visualized as the value being a twin of the definition. Thus, a value can be associated with each definition at all levels of the structure. Initially, a data definition has no data values; they are added by the Precede command. When added, only those values are added which are required to provide concatenation with the highest level within the data structure. Conversely, if no value exists for a given definition, then no values exist for any subordinate definitions of that definition.

An example of the side-by-side nature of a definition and its value is seen when assigning a value to the definition of [Child's Sex]. To assign a current value to [Child's Sex], a Precede command is executed to Precede [Child's Sex] with [Female]. The execution associates the value of [Female] with [Child's Sex]. FIGS. 14(a) through 14(d) shows both the definition and the value of [Child's Sex] before and after the command is executed.

The example in FIG. 14(b) shows that before the procedure execution, no value is associated with [Child's Sex]. After execution, FIG. 14(d) shows that the value [Female] has now been associated with [Child's Sex]. Note that [Female] is not duplicated here; both structures are associated with the same [Female]. This association of a value with its definition is performed by a database set connection, as are all associations in a fractal environment. Thus, in the case of a data definition with a single value, the minor inconsistency is bypassed.

Having defined the one-to-one relationship, the next step is to define the case of the one-to-many relationship, such as with a child's name that consists of many letters.

To understand the multiple value case, begin with a single value case as shown in FIGS. 15(a) through 15(d). The figure shows both the definition and the value for [Child's Name] as they appear before and after the "Precede [Child's Name] with [A]" command is issued.

FIGS. 15(a) through 15(d) show how the first letter of the name is associated with [Child's Name]. Subsequent letters can be easily added in the same manner; the new values are added to the structure via the Precede command, as described above.

To associate [Child's Name] with the data values [A], [d], and [a], simply issue the Precede command three times: once for [A], once for [d], and once for [a]. The result is that all three letters are associated as values of [Character], with [Character] being associated as a value of [Child's Name].

A rendering of the internalization of multiple values can be done, but is not necessary at this time. An informal presentation of the re-drawing of FIGS. 15(a) through 15(d) appears in FIGS. 16(a) through 16(d). The figure shows the structure before and after the three Precede commands.

The structure in FIG. 16(d) shows the association of the three added data values by using a "third dimension" perspective. Discussion of a more-formal presentation of one-to-many relationships is given later.

Because of the fractal nature of the data structure, multiple occurrences of any data value can occur at any point in the structure. All are connected via the single icon, the database set connection.

2.4.5.2 Procedure Definition versus Procedure Value

It is also necessary to discuss the distinction between the definition of a procedure and the value of a procedure. All examples of procedure structures thus far have been examples of the definition of a procedure. As with data definitions, procedure definitions can have a value as well. The purpose of a procedure value is to mark the currently-executing Line in the procedure definition. The value of a procedure is analogous to a pointer which indicates which line of a subroutine is currently being executed. The procedure value exists only during execution of the procedure, and is not seen by the programmer. The procedure value is used internally by the system. Note, however, that a given procedure may have many values, i.e. the procedure may be "called" several times simultaneously in a multitasking environment. When the execution of a procedure is begun, a value is associated with that procedure. Associated with that value are all internal database connections which are required to control and monitor that execution. As each subordinate is invoked, this procedure value moves from the current procedure definition to the first subordinate of that procedure. Execution proceeds in hierarchical order until the value returns to the starting point; then the execution ceases and the value is deleted. Multiple executions of the same definitions can proceed simultaneously.

2.4.5.3 Directory Definition versus Directory Value

Since directories are executable, the value associated with them behave in the same manner as any procedure value.

In summary, the relationships among the main components of a fractal environment are as follows: Directories are made up of procedure structures, that is, executable Contexts; Contexts are composed of data and the procedure which acts on that data. Directories, procedure and data are composed of database set connections alone. The definitions and values of three components, data structures, procedure structures, and Directories, are constructed completely from database set connections alone. Taken together, these components can entirely define any data or procedure in a fractal environment.

3. Syntax of the Present Invention

This section includes a detailed explanation of the syntax used in the present invention.

3.1 General Syntax Overview

As described above, any data, procedure, or directory can be described as a fractal "shape" constructed of database set connections alone. Any portion of this fractal "shape" is called a Chart. A Chart is used to depict any data, process, or directory using only the single fractal "curve", the database set connection.

The environment of the present invention uses a graphic representation to show the presence of these database set connections rather than using a language-based representation. The graphic used to represent a database set connection is a near-vertical bar (called a Line) with comments enclosed in a rectangle (called a Box) at the base of the Line. Strictly speaking, the Box and the Line are part of a single unit; the Box serves only as a comment to the programmer as to the purpose of the Line. However, the relationships are easier to visualize and manipulate if the Box and Line are considered as independent units.

All Charts are constructed from the two elements, namely Boxes and Lines. Boxes are used to describe an element, while Lines show the connections between elements. Comments enclosed within the Box serve to document the purpose of each connection.

In summary, Boxes and Lines (i.e., the elements of a Chart) are interconnected to form Data, Procedure, and Directory Structures. The environment of the present invention serves as the operating system which uses these structures as replacements for traditional programs and files. A more detailed discussion of Boxes and Lines is given below.

3.1.1 Boxes

As stated above, one of the two elements of any Chart is the Box. Boxes exist only to hold programmer-defined comments. Boxes fall into three categories: Data Boxes, Procedural Boxes, and Directory Boxes. All three kinds of Boxes are identical; the differing types only refer to their differing application.

Every Box has a Name. The Name is some identifying pattern which differentiates this Box from all other Boxes in the environment. A Name can be text, numeric, binary, graphic, or any other identifying pattern.

In a programming environment, though, a few naming conventions can be established. The form of the Name in a Box can depend on whether it is a Data, Procedure, or Directory Box. Data Boxes usually contain a short noun phrase which exemplifies the data being represented. Procedural Boxes contain a short imperative phrase which describes the action being performed. Directory Boxes serve merely to provide meaningful names for the collection of Contexts and Directories which they represent. Some examples of Data Boxes are shown in FIG. 17. Examples of Procedural Boxes are shown in FIG. 18. Examples of Directory Boxes are shown in FIG. 19.

Note that there is no significant difference between a Data Box, a Procedure Box, or a Directory Box, except for the form of the Name which appears inside. Even this minor distinction is just a suggestion, not a requirement. The text in the Boxes does not need to follow any rules. The text is only a comment, not used by the system, for identifying a particular box to the programmer. It can contain any characters, symbols, graphics, Boxes, screen maps, video image, or whatever identifying patterns are desired. It may be a short, bland reminder, or an essay of infinite length. FIG. 20 shows two different styles of Box Names for data identifying a number.

Throughout this specification, when a Box Name appears in a paragraph of text, it is written within brackets to show that it is a Box Name. For example, the first Box in FIG. 20 is rendered as "[EMPNUM]", and the second one as "[The number of the employee who will be the first one monitored if a suspicious act is noticed.]".

Internal to the environment of the present invention, Box Names are not used. Instead, the environment assigns to every Box a unique internal name. Whenever a Box is accessed, the internal name is used exclusively. Only when a Box is being requested by its Box Name, as a human operator would do, is the Box Name used. Thus, the external Box Name can be changed at will; the internal name always remains the same.

A level of security can be achieved with a structure where all Box Names have been removed. Without the Box Names to guide the human, the effort required to make sense of a structure would be enormous. Other security features are described later.

Since the environment of the present invention does not require unique (or any) Box Names, duplicate Box Names can be used. A detailed explanation of the Box Name search rules will be given later.

3.1.2 Lines

The Lines are used to indicate the actual database set connections between Boxes. For Data Boxes and Directory Boxes, the Lines represent the association of the various components of a Data Structure. While this is true of Procedure Boxes as well, the Lines also determine the sequence of execution.

Lines always join two Boxes together. The Lines are drawn vertically, or nearly vertically, in the examples given herein. But horizontal or other connections between Boxes can be used as well. The orientation is not critical, but the implementation discussed herein assumes the use of near-vertical Lines.

Relative to a Line, a Box can be either an Owner Box or a Child Box. The difference between an Owner and a Child can be summarized as follows:

The Box at the top of a Line is referred to as the Owner of the Box at the bottom of that Line.

The Box at the bottom of a Line is referred to as the Child of the Box at the top of the Line.

When an Owner Box is joined to a Child Box with a Line, the Owner is "associated" with the Child. An Owner Box can associate with any number of Child Boxes. A Child Box can be owned by any number of Owner Boxes. A Box can be its own Owner Box, and, as such, one of its own Child Boxes as well. Recursive structures are readily implemented with fractal notation.

The use of Lines to connect Boxes in a fractal environment can be contrasted with some concepts from a traditional environment. The relationship between two Boxes joined by a Line can be described in one of three ways:

The relationship between a Data Box and its Child Boxes can be envisioned as being identical to the relationship between a record and its fields.

The relationship between a Procedure Box and its Child Boxes can be envisioned as being identical to the relationship between a calling program and its subroutine.

The relationship between a Directory Box and its Child Boxes can be envisioned as being identical to the relationship between a hierarchical directory and its subdirectory or the directory's contents.

When the sequence of Boxes in a Chart is significant, the Lines of a Chart are traversed in hierarchical sequence, that is, top to bottom, left to right.

3.2 Data Charting Notations

Having defined the two elements of a Chart, structures can be defined which use these Elements. The following discussion describes the method of joining Boxes and Lines to form Data Charts, also referred to as Data Structures.

From a theoretical point of view, there is only one kind of Line: the database set connection. However, in order to bring visual clarity to the purpose and usage of Lines in a Data Structure, the formal syntax of the present invention includes three different presentations of Lines. These three kinds of Lines are called Synchronous Lines, Asynchronous Lines, and Enumeration Lines. Their purpose and usage are described in the following sections.

3.2.1 Synchronous Lines

The first kind of Data Line is a Synchronous Line. This Line is used to denote a direct one-to-one relationship between an Owner Data Box and its Child. FIG. 21 shows an example of a Synchronous Line.

The example states that an [Employee Name] consists of three parts: one [First Name], one [Middle Name], and one [Last Name]. It does not state what a [First Name], [Middle Name], or [Last Name] might be; since they have no Child Boxes, those Boxes are undefined (i.e., their Child Box is the Null Box).

3.2.2 Asynchronous Lines

The second possible representation of a Line is called an Asynchronous Line. This Line is used to denote a traditional database set connection, an array, or any one-to-many relationship. The syntax consists of a dashed line rather than the solid line used for the Synchronous Line. A sample of an Asynchronous Line is given in FIG. 22. An Asynchronous Line can be viewed as a set of many Lines, each connected to a separate box, such that the Boxes are in a particular order.

This example shows that an [Employee List] consists of zero or more [Employee Name]s. If a solid, Synchronous Line was used instead, FIG. 22 would then show that an [Employee List] contains only one [Employee Name]. Note that no size is specified; the list of [Employee Name]s is potentially infinite in length. Thus, one can view the box [Employee Name] as a set of many Boxes, arranged in a particular order, and each connected to [Employee List], its Owner Box.

3.2.3 Enumerations

The third type of Line is the Enumeration Line. This Line is used to show where a choice of values for a Data Box exists. For example, FIG. 23 shows the various values available for [Arrival].

This example shows that there are three types of [Arrival]: either [Early], [On Time], or [Late].

The Enumerative Line indicates the bottom level of a Data Structure. For Data Structures, they always (and only) associate the lowest-level Child Data Boxes (called Enumerants) with their Owner Boxes (called an Enumeration). The connections define the only possible non-null Data Values which can be assigned to the Enumeration. For example, if a Data Value is to be assigned to [Arrival], that Value must be one of the three defined Enumerants or remain undefined.

3.3 Procedure Charting Notations

The above discussion presented Boxes and Lines as components of Data Structures. The following discussion presents Boxes and Lines as components of Procedure Structures. As with Data Structures, some alterations in the Chart format have been introduced for the sake of visual clarity. There are four kinds of Procedural notations: Synchronous Lines, Asynchronous Lines, Iteration, and Enumeration selection.

3.3.1 Synchronous Lines

The first kind of Procedure notation is the Synchronous Line. This Line denotes a direct, synchronous transfer of execution control to a Procedure Box (the Child Box) from another Procedure Box (the Owner Box). The syntax for this kind of Line is a solid line between the two Boxes. The Owner Procedure Box invokes the Child Procedure Box below it; when the Child has completed executing, control is returned to the Owner Box. The relationship between an Owner Box and its Child Box is identical to the relationship between a calling program and its subroutine.

An example of the usage of the Synchronous Line from a procedural point of view is shown in FIG. 24.

The sample procedure structure shows that [Print Page] consists of three subroutines: [Print Header], [Print Lines], and [Print Trailer]. The execution of [Print Page] involves the execution of [Print Header] first, then [Print Lines] next, and finally [Print Trailer]. Note that each of these three subroutines also have their own Child Boxes (not shown) which are executed as a part of performing their respective functions.

3.3.2 Asynchronous Lines

The second kind of Procedure notation is called the Asynchronous Line. This Line is used to denote the asynchronous invocation of a Child Box, that is, the Child Box is invoked as an independent task which does not return control to the Owner Box. Conversely, the Owner does not wait for the Child to return control, but rather, the Owner continues execution as if the Child had already returned control.

An example of an Asynchronous Line is given in FIG. 25. In this example, [Start a New Task] initiates the execution of [Run Task], then returns control to the Box which called [Start a New Task]. The Procedure named [Run Task] continues executing independently of the initiating Procedure.

The only difference between the Synchronous and the Asynchronous Lines is that with the Synchronous Line, the Owner Box waits for the Child Box to return control; with the Asynchronous Lines, the Owner Box continues execution immediately without waiting for the Child Box to return control.

Despite the difference in appearance and function from the Synchronous Line, there is still only one type of database set connection at work. Internally, the Asynchronous Line is not represented differently from a Synchronous Line; instead it is a translation of a Procedure Structure. This translation is described in more detail later.

3.3.3 Enumerations

The third kind of Procedure notation is the Enumeration Line. This Line is used to allow selection of an individual Procedure Box from many choices. The criterion for this selection is based on the Value of a Data Box. For example, if a Procedure Box picks an action based on a worker's arrival status, the Chart would appear as shown in FIG. 26.

Note that the notation "Arrival" along one of the lines matches the Data Enumeration Box named [Arrival] in the Data Structure in FIG. 23, while the notations "Early", "On Time", and "Late" match the names of the Enumerants of [Arrival ].

When the Chart in FIG. 26 is executed, the determination of which Child Box to execute depends on the current Value associated with [Arrival]. If no Value is associated with [Arrival], or if the Value associated with [Arrival] is undefined or anything other than [Early], [On Time], or [Late], then the unlabeled Child Box [Handle Unknown Arrival] is invoked.

Despite the difference in appearance and function between an Enumeration Line and a Synchronous Line, there is still only one type of database set connection at work. Internally, the Enumeration Line is not represented differently from a Synchronous Line, rather it is a translation of a Procedure Structure. This structure is discussed in more detail later.

3.3.4 Iteration

The fourth kind of Procedural notation is called Iteration. Iteration allows an Owner Box to invoke repeatedly its Child Boxes. The syntax for Iteration includes notation providing a condition for termination. For example, a file-printing Procedure Structure might appear as shown in FIG. 27.

Note that the position of the Iteration notation is critical. The evaluation of the condition occurs at the point where the notation is located. In this example, the condition is evaluated after [Read Record], but before [Print Record]. Thus, [Print Record] is not invoked if a [Missing] [Record] is returned by [Read Record]. Here, it is assumed that [Record] and [Missing] are Data Boxes which have been defined elsewhere. Note also that, in the termination condition "Until Record Is Missing", the terms "Record" and "Missing" will be interpreted by the system to indicate previously defined Data Structures having these names.

Despite the difference in appearance and function between an Iteration and a Synchronous Line or an Enumeration, there is still only one type of database set connection at work. Internally, Iteration is not represented differently from any other Procedure Structure; instead, it represents the translation of a Procedure Structure. This structure is discussed in more detail later.

3.4 Context Charting Notation

Having defined Data and Procedure Charts and their composition, the integration of data with procedure is the next step. The following paragraphs present the syntax for the Context, the named integration of Data and Procedure Structures.

Data Charts and Procedure Charts are not independent entities in the environment of the present invention. Instead, they are tightly bound into a single unit which is referred to as a Context. A Context is an executable structure which is similar to a subroutine in many ways. For example:

a Context can be called from other Contexts, possibly returning control to the calling Context after completion;

a Context contains local-data which cannot be directly accessed from outside that Context;

argument passing is supported between the calling and the called Context in much the same manner as subroutine arguments;

a Context has a name, just as a subroutine would; this name appears in the top Procedure Box of the Context.

Briefly stated, a Context consists of those Procedure Structures which service the Data Structures contained within the Context. A Context is the "Keeper of the Data" in that no Context can access the data which is contained within another Context. All interaction between Contexts is channeled through a rigidly defined interface which passes arguments into or out from a Context.

The following sections describe the use of Contexts in the environment. Specifically, they cover the naming of Contexts, the passing of arguments into and out from a Context, and the checking of the data types of any Context arguments.

3.4.1 Context Names

Every Context has a Context name. A Context name does more than merely identify the Context; the name also identifies the Context's Arguments. All data is passed into and out from a Context by means of Argument Boxes. Argument Boxes are entered directly into the Context Box Name, just as any other character in the Name. Some examples of Context Box Names are shown in FIG. 28.

FIG. 28 shows three sample Context Boxes. The first one represents a subroutine which returns a character stored in [Char]. The second uses [Bad #] as an input for error reporting. The third Context accepts an argument whose Value becomes associated with [Argument Box Name].

The examples in FIG. 28 present the form of a Context Box Name. However, the presentation of a Context Box Name can vary slightly depending on the point of view. There are two ways of viewing any Context. One way is from the calling side; the other, from the called side.

FIG. 29 shows the calling side of a Context which increments a page number, while FIG. 31 shows the called side of the same Context.

In the example shown in FIG. 29, the Box named [Page Number] is the Argument Box of the Context, indicating the data value to be incremented. As with all of the calling Context's data, it must be defined as a part of the Data Structure of the calling Context. The Data Structure for [Page Number] is shown in FIG. 30.

Remember that there is a difference in the presentation of the Context name which depends on the point of view. FIG. 29 showed the Context Name from the calling point of view. From the called Context's point of view, the Context Box Name appears as shown in FIG. 31.

Beneath this Context Box are the individual Boxes which actually perform the increment. Note that the name given to the Argument Box within the Context need not be the same as the name supplied by the caller. It must, however, be of the same data type which, in this case, would be the data type that consists of many Digits. More information relating to data types will be given below.

3.4.2 Context Arguments

The Argument Boxes can be used to pass data Values into a Context or return values out from a Context. Many Argument Boxes (either Data, Procedure, or Directory Boxes) can appear within the name of a Context. A Context with multiple Argument Boxes would appear as shown in the example in FIG. 32.

The two Argument Boxes, [Maintain] and [Name], must be defined as a part of the Context's Data Structure. The Data Charts for the Boxes [Maintain] and [Name] are given in FIGS. 33(a) and 33(b).

Having defined the Context and its Argument Boxes, it becomes possible to view the Context from the calling side. Suppose another Context wishes to add a new name to the list. Assuming that the calling Context has defined [A New Name] as being composed of many [Character]s (i.e., of the same data type). Then the calling Procedure Structure could contain the Box shown in FIG. 34.

The Values associated with the Argument Boxes listed in the Context name are transferred into the Context; the called Context processes the request while the calling Context waits for completion of the [Add] request. Note that the [Add] request of FIG. 34 is the same [Add] which appears in the Data Chart for [Maintain], shown in FIGS. 33(a) and 33b).

Many Contexts can invoke the same Context. Since the environment of the present invention is a multitasking environment, provisions are made for simultaneous access. Should a Context be busy processing a prior request, the next request is queued onto the Context to wait until the Context is available to process the queued request.

It is the responsibility of the called Context to decide whether to preserve any data from one invocation to the next, or to delete all data after each completion of its function.

As with all other Box Names within this document, whenever a Context Box Name is used in a sentence, brackets are used to denote both the Context Name and the Argument Boxes. For example, the Context Box in FIG. 32 is written as "[[Maintain] [Name] In List]". It is possible to adopt other notations, within the scope of the invention.

3.4.3 Context Argument Data Types

Data types are rigorously enforced across the Context interface. The data type of a Box is defined as the arrangement and names of the Boxes which are subordinate to that Box. The data types of the Argument Boxes in the calling Context must match the data types of the Argument Boxes in the called Context.

To determine if two Boxes have the same data types, apply the following tests:

1. Two Boxes are the same type if one of the Boxes is the sole Child Box of the other via a Synchronous Line.

2. An Enumeration and its Enumerants are always the same data type.

3. Two Boxes are the same type if they are both the same type as some third Box, that is, the transitivity rule of equality applies.

These rules are simple in practice. As examples, FIG. 35 shows two similar Data Structures.

In FIG. 35, each of the data type rules is exemplified. For example:

by rule #1, [Valid] is the same data type as [Good Inputs] because one is the sole Child Box of the other via Synchronous Line;

by rule #2, [Valid] and [#] are the same data type; so are [@], [*], [$], and [%], as well;

by rule #3, [Good Inputs] and [Valid] are both the same data type; [Special Characters] and [Valid] are both the same data type; by extension, [Good Inputs] and [Special Characters] are the same data types, too;

by any rule, [Two Similar Data Structures] is not the same data type as any other Box in the example.

According to the data type rules, the data types of an Owner Box and a Child Box are the same if the Child Box is the only Child of the Owner and if they are connected by a Synchronous Line. If an infinite number of Boxes were created, each as the sole Child Box of the preceding Child Box, all of these Boxes would all be the same data type.

One major benefit of the fractal definition of data types is that a given Data Box can participate in several different Enumerations at the same time. For example, note that all of the Enumerants of [Valid] also happen to be Enumerants of [Character] (from an earlier example). While this does not mean that [Valid] is the same data type as [Character], it does mean that [#] of [Good Inputs] has the same data type as [#] of [Special Characters].

In summary, whenever a Context Box is referenced, the data type of the Argument Box which is supplied in the interface must match the data type which was defined for the Argument Box in the top Box of the Context.

3.5 Directory Charting Notation

With the definition of the syntax for Contexts complete, the next step is to define a mechanism to interconnect Contexts. In the environment of the present invention, Directory Boxes are used to group related Context Boxes together for any reason.

An example of the usage of Directory Boxes is given in FIG. 36. This example shows that under the top Directory Box [Top Box] there are three subdirectories: [Test], [???], and [Prod]. Under the Directory Box named [Test], there are two Context Boxes: [Send [Text]] and [Get [X]]. Under the Directory Box [???], there are no Context or Directory Boxes. Under the Directory Box [Prod], there are two members: a Context Box [Add 1 to [N]] and a Directory Box [Old Prod]. The Directory Box named [Old Prod] also contains subdirectories or Contexts which are not shown in the example.

The Directory Boxes form the highest level of the hierarchy of all Boxes. For example, tracing upward through any hierarchy of Data or Procedure Boxes leads first to a Context Box, then to the Directory Box which holds that Context. Tracing upward further through all Directory Boxes, the ultimate goal is reached: [Top Box]. This Box is the root Directory Box, the single Box to which all other Boxes are connected.

One handy feature of Directory Boxes is that they can be executed, just as any Procedure Structure, because [Top Box] is actually a Context Box without any Argument Boxes. Thus, Directories can serve as a command language. Should a Directory Box be executed, the effective result would be to execute each of the Directory's Child Contexts. This is useful as a programming technique when starting the execution of a group of stand-alone Contexts or with a series of often-repeated Contexts.

3.6. Pre-defined Boxes

In order to provide full programming capabilities within the environment of the present invention, some Data Boxes, Directory Boxes, and Contexts are pre-defined. These Pre-defined Boxes form the base on which the entire environment is built. There are three kinds of pre-defined Boxes: Pre-defined Data Boxes, Pre-defined Procedure Boxes, and Pre-defined Directory Boxes.

3.6.1 Pre-defined Data Boxes

There are only two types of pre-defined Data Boxes: the Null Box, named [], and Device-specific Boxes. All other Data Boxes are built from these.

3.6.1.1 The Null Box

One of the Pre-defined Boxes is the Null Box. The Null Box is not actually a Box at all, but rather, it represents the absence of a Box.

The Null Box can be employed in several ways. Replacing a Box with a Null Box is equivalent to deleting that Box. The Null Box is returned after a Locate Next as an end-of-set condition. It is also returned for every Locate command that fails to locate data. Being no Box at all, the Null Box has no data type at all. Being typeless, it can be used to match any type at all. The Null Box does not have any Child Boxes. It is automatically included as the first Enumerant of any Enumeration to represent the "undefined" Value for the Enumeration.

The Null Box is represented in one of two ways. When used as a part of any Structure, the Null Box and the Line above it are not drawn. When used as an Argument Box in a Context Box, it appears as an empty Box. The appearance of the Null Box is shown in FIG. 37.

Note that as a Child Box in a Data, Procedure, or Directory Structure, the Null Box is not displayed. Within a Context Box, however, the Null Box is displayed as an empty Box to indicate that no Box is being passed as an Argument Box.

3.6.1.2 Device-Specific Data Boxes

No Pre-defined Data Boxes exist in the environment of the present invention except the Null Box, []. However, when any external devices are integrated into that environment, the new device implies the existence of certain Data Boxes associated with that device. For example, integrating a keyboard into the environment implies the integration of the set of keyboard characters as Data Boxes.

New Pre-defined Data Boxes must be introduced whenever an external device, such as a terminal or tape drive, is connected to the environment of the present invention. For example, the letter "A" cannot exist in a Data Structure until some device is connected which can supply some A's. Also, non-textual devices such as a video camera can be integrated; the Pre-defined Data Boxes associated with the camera would contain video pictures rather than pictures of text characters.

In the example of adding a keyboard device, the Data Boxes specific to that device consist of one Box for the letter "A", one for the letter "B", and so on, with one Box for each possible value which can be entered via keyboard. This implies that in order to perform any meaningful work within a fractal environment, some external device must exist or else no data is possible. Thus, the scope of the data acquired from all external devices determines the theoretical scope of what can be processed as data. The environment of the present invention is only limited by the capabilities of its peripheral devices.

3.6.2. Pre-defined Procedure Boxes

There are eight Pre-defined Procedure Boxes. Of these eight Contexts, three are used to manipulate the database, and five are used for procedure control. These pre-defined Procedure Boxes are: Locate, Precede, and Delete (for database manipulation), and Invoke, Iteration, Enumeration, Accept Argument, and Return Argument (for procedure control). Note that some of these Pre-defined Procedures correspond directly to the database control commands discussed above. That is, these Pre-defined Procedures implement the control commands discussed earlier.

3.6.2.1 Locate

The Locate Context is used to establish position within the database. There are two forms of the Locate Context: one for keyed access and one for positional access. The two forms of the Locate Context Box are shown in FIG. 38.

The first form of the Context has two Argument Boxes. The first Argument Box, [Which], specifies which occurrence is to be Located, either [First], [Last], [Next], or [Prior]. Its use in the second form ensures that all Data Boxes with identical key values can be accessed. The Data Chart for [Which] appears in FIG. 39. The values in FIG. 39 are pre-defined; the programmer inserts a value for [Which] as desired.

Both forms of the Locate Context have a second Argument Box. This Box specifies the Data Structure whose Value is to be Located. Since the Null Box defines this Argument Box, any data type can be used here. Once Located, the entire Data Structure, from the next-highest Asynchronous Line on down, becomes the current Value. The current Value is the value on which the system is currently operating. In other words, when the system Locates a name, all Data Boxes associated with that name become "current".

An example of the usage of the Locate Context is shown in FIG. 40. It is based on the Data Structure shown on the right-hand side of FIGS. 41(a) through 41(c), which is a list containing many [Name]s. The example shown in FIG. 40 finds the first [Name] in the [Name List].

The second form of the Locate Context has a third Argument Box. This Box is used to specify a key value, that is, it pinpoints the occurrence which is to be Located and made the current Value. Since the Null Box is used to define this Argument Box, any data types can be used here. However, it must match the data type of the second Argument to prevent ambiguity.

If the Locate succeeds, the first Value for [Name] in the [Name List] is made ready for access. If it fails, the Null Box is the Value for [Name ].

As an example of the second form of the Locate Context, Locate the [Name] in the [Name List] which corresponds to [Some Name]. The calling Context and the associated Data Structures would appear as shown in FIGS. 41(a) through 41(c).

The example in FIGS. 41(a) through 41(c) requests that the value of [Name] in the [Name List] which corresponds to [Some Name] be made the current value. If the Locate fails, no occurrence is made current; the current value of [Name] becomes undefined, that is, the Null Box []. FIGS. 41 includes the data definitions for [Some Name] and [Name List].

3.6.2.2 Precede

The Pre-defined Precede Context is used to add Values to a Data Structure. The format of the Precede Context is shown in FIG. 42.

Two Argument Boxes are needed to use this Context. The first Argument Box specifies the Data Structure which is to receive a new Value. This Box need not appear below an Asynchronous Line.

The second Argument Box indicates the Value which is to be added. It must match the data type of the first Argument Box.

When invoked, this Context adds the Value of the Data Box indicated by the second Argument as a new member of the Data Structure indicated in the first Argument. The new Value is added prior to the currently-Located value. Before executing this Context, the current position in the Data Structure must be established using the [Locate [Which] []] Context. If no occurrence is current, that is, if the Null Box is current, then the new member is added as the last occurrence. After the new data are added, the previously-Located value remains current.

No status is returned by this Context; it always executes successfully.

3.6.2.3 Delete

The third Pre-defined Context which is used for database control is the Delete Context. This Context is used to remove values from the database. Before it can be used, the position in the Data Structure must first be determined by using the Locate Context. The form of the Delete Context is shown in FIG. 43.

Only one Argument Box is needed to use this Context. It specifies the Data Structure whose value is to be Deleted. The Box named as the Argument can appear anywhere in a Data Structure.

When invoked, this Context removes the Located Value from the Structure indicated in the Argument Box. If no occurrence is currently Located, no action occurs. After invoking this Context, no Value remains current.

No status is returned by this Context; it always executes successfully.

3.6.2.4 Iteration

The fourth of the six Pre-defined Procedure Boxes is the Iteration Context Box. This Context controls the repeated execution of other Procedure Boxes.

Although the Charting technique for Iteration may not obviously reflect it, the internal representation for Iteration is structured as a Context. When this Box is used in a Chart, the Context Box is not displayed; instead, the Iteration notation is displayed (Cf. Section 3.3.4, Iteration).

The Context Box format for Iteration is shown in FIG. 44.

When invoked, the Iteration Context uses the supplied [Relation] to compare the Values associated with each supplied Argument Box. If the result of the comparison is true, then the Owner Box execution is immediately aborted; execution of the Procedure continues with the next Child Box of the Owner of the Owner of this Context. If the result of the comparison is false, execution continues normally with the next Child Box of the Owner of the Iteration Context.

As an example of how the Iteration Context operates, FIG. 45 shows a program which deletes all names in the list of names from FIG. 32.

The Chart in FIG. 46 re-draws the Chart in FIG. 45, using the standard Iteration notation. Both FIGS. 45 and 46 reflect the same Structure; the first is the actual internal representation while the second is the displayed representation.

In the sample Structure [Erase All Names], the two Child Boxes are executed repeatedly until the condition [Until [Name] [Is] []] evaluates as true; when it does, the Owner Box of the Iteration Context (i.e., Erase All Names]) is immediately aborted and control returns to the Owner of [Erase All Names] (not pictured in the examples).

There are eight possible Enumerants which can be used as a [Relation]. Those Enumerants and their meanings are presented in the following table.

    ______________________________________
    [Relation]
              Comparison result
    ______________________________________
    [=]       True when the Values associated with the two
              Argument Boxes correspond Value for Value at
              all levels, that is, one Structure is a
              duplicate of the other
    [Not =]   True when the Values associated with the two
              Argument Boxes do not correspond Value for
              Value at all levels
    [Is]      More precise than [=], the comparison is
              true only when the Argument Boxes are both
              associated with the exact same Value, not
              merely a duplicate of the Value
    [Is Not]  True when the value associated with the
              first Argument Box is not the same Value
              associated with the second
    [>]       True when the number of Values associated
              with the first Argument Box exceeds the
              number of Values associated with the second
              Argument Box. If the numbers of Values are
              the same, then the comparison is based on the
              relative position of the Enumerants in the
              Enumeration. For example, if the Values are
              numbers, they would be compared according to
              numerical values. The Values need not be
              numbers, however.
    [Not >]   True when the number of Values associated
              with the first Argument Box does not exceed
              the number of Values associated with the
              second Argument Box
    [<]       True when the number of Values associated
              with the second Argument Box exceeds the
              number of Values associated with the first
              Argument Box
    [Not <]   True when the number of Values associated
              with the second Argument Box does not exceed
              the number of Values associated with the
              first Argument Box
    ______________________________________