System and method for managing memory

BACKGROUND

[0001] 1. Field of the Invention

[0002] The invention relates to managing memory, and in particular to providing a data storage system for an application to use in accessing data.

[0003] 2. Background Information

[0004] Document data is increasingly being stored and/or processed in a structured format using a data structure standard. In particular, data structure standards are used to provide a set of definitions that can be used to separate data content from a particular presentation. In this manner, the content can be quickly accessed and re-rendered in a different context. It has previously been recognized that by separating content from presentation it would be possible to share data on a platform-independent basis. One such early effort was the Electronic Data Interchange (“EDI”). Similarly, the Hypertext Markup Language (“HTML”), which has enjoyed widespread acceptance over the World Wide Web, represents another effort to normalize document data structures for facilitating the sharing of data between different computer systems.

[0005] While many data structure standards have been developed, one exemplary standard which has gained widespread recognition is the Extensible Markup Language (“XML”). XML, like HTML, evolved from the Standard Generalized Markup Language (“SGML”). XML is a document-based organizational standard that provides a set of rules for defining descriptions of structure and content in a document. XML uses tags that are similar to HTML tags, except that HTML tags provide a way of formatting information, while XML tags only organize and describe the data itself. That being the case, it is typically the case that XML documents must be parsed using a processing algorithm, as must XHTML and SGML documents.

[0006] Regardless of the data structure standard in use, there are two dominant approaches to navigating document data. The first type of navigation method, or parser, reads the document and transforms the data into its tree-structured equivalent. The most common example of this is the Document Object Model (“DOM”), which is based on the notion of using nodes to navigate a document. DOM, and other tree-based parsers, enable application programs to navigate and manipulate document data by loading and storing the entire document in this tree structure. However, this approach suffers from the fact that it is a strong consumer of memory resources. A DOM version of a document can easily consume two to three times as much memory as the original document would have. This can have a significant impact on applications which run in memory-poor environments, such as would be the case with embedded system applications.

[0007] The second approach to parsing document data is to analyze the document as a stream of text, rather than as a tree. In particular, as the various components of a document are encountered, the parser raises events (such as start and end elements), and reports such events back to the application program. A common example of an event-based parser is the Simple API for XML (“SAX”), which reports events to the application program using callbacks, which cause the application program to implement event handlers for the different types of events. While the event-based parser of a document requires much less memory than its DOM version would, event-based parsers can only process the current node and those nodes that are younger siblings or children of the current node. Moreover, the application program will have no control over the navigation through the document data.

[0008] Accordingly there is a need in the art for a system and method of managing memory which does not suffer from the aforementioned drawbacks.

BRIEF SUMMARY

[0009] A system and method for accessing data by an application program is disclosed. In one embodiment, the method comprises issuing a request, by an application program, for a reference, and storing a node in a memory as part of a data structure in response to said request, said data structure to include at least a portion of a data set and to be organized as a plurality of nodes. The method further includes returning the reference to the application program, and accessing the node, by the application program, using the reference.

[0010] Other embodiments are disclosed and claimed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011]FIG. 1 is a block diagram of one embodiment of a processor system <b>100</b> capable of implementing a data storage system, according to the principles of one aspect of the invention.

[0012]FIG. 2 is a block diagram of another embodiment of processor system <b>100</b> capable of implementing a data storage system consistent with the principles of one aspect of the invention.

[0013]FIG. 3A is a block diagram illustrating one embodiment of data storage system interaction.

[0014]FIG. 3B is a block diagram illustrating another embodiment of data storage system interaction.

[0015]FIG. 4 is a process diagram of one embodiment of a process of handling application program requests by a data storage system, in accordance with one aspect of the invention.

[0016] FIGS. <b>5</b>A-<b>5</b>E are block diagrams of various possible memory usage states.

[0017]FIG. 6 is a block diagram depicting one embodiment of the node states and node transitions of one aspect of the invention.

[0018]FIG. 7 is a block diagram depicting one embodiment of navigation functions of a data storage system, in accordance with one aspect of the invention.

DETAILED DESCRIPTION

[0019] One aspect of the invention relates to providing a system for parsing document data which is to be provided to an application program in response to a request from the application program. In one embodiment, this functionality is provided by a data storage system which receives and parses data, such as document data, from a data source. The data storage system parses a data set to determine node boundaries and relationships, and creates a data structure in memory comprised of nodes. In one embodiment, the scope of the data structure created by the data storage system corresponds to application program requests and represents some fraction of the total data set. In one embodiment, the requests are navigation function calls which cause the data storage system to load a desired node into the data structure in memory. The data structure may be stored in shared system memory that is accessible by both the application program and the data storage system, according to one embodiment. The data structure may be updated by the data storage system based on subsequent application program requests.

[0020] Another aspect of the invention relates to providing a system for an application program to navigate through document data and access specific nodes of the data structure. This is done by returning references to the application program corresponding to the desired nodes. A reference may be a physical memory address where the node is stored, or may be a virtual memory address. It should be appreciated that the reference may also be a table index, an associative memory address, or any other means of identifying a storage location for the node sought. In one embodiment, when an application program issues a navigation function call to the data storage system, the data storage systems updates the data structure in system memory as needed, and returns one or more references to the application program corresponding to the requested node(s). The application program may then access the nodes in the data structure using the corresponding references returned to it.

[0021] Yet another aspect of the invention relates to releasing nodes from the data structure, when no longer being used by the application program. In one embodiment, nodes are de-allocated (i.e., have no effective reference assigned), but are yet retained in memory. In another embodiment, nodes that are de-allocated are also discarded from system memory. In another embodiment, de-allocated nodes are discarded from memory automatically, while in another embodiment, de-allocated nodes are discarded from system memory as a function of system memory limitations.

[0022] Referring now to the figures, one embodiment of a processor system <b>100</b> that implements at least one aspect of the invention is depicted in FIG. 1. Processor system <b>100</b> comprises a processor or a central processing unit (CPU) <b>104</b>. The illustrated CPU <b>104</b> may include an Arithmetic Logic Unit (ALU) for performing computations, a collection of registers for temporary storage of data and instructions, and a control unit for controlling operation for the processor system <b>100</b>. In one embodiment, the CPU <b>104</b> includes any one of the x86, Pentium™, Pentium II™, and Pentium Pro™ microprocessors as marketed by Intel™ Corporation, the K-6 microprocessor as marketed by AMD™, or the 6x86MX microprocessor as marketed by Cyrix™ Corp. Further examples include the Alpha™ processor as marketed by Digital Equipment Corporation™, the 680X0 processor as marketed by Motorola™; or the Power PC™ processor as marketed by IBM™. In addition, any of a variety of other processors, including those from Sun Microsystems, MIPS, IBM, Motorola, NEC, Cyrix, AMD, Nexgen and others may be used for implementing CPU <b>104</b>. Moreover, the CPU <b>104</b> is not limited to a microprocessor, but may take on other forms such as microcontrollers, digital signal processors, reduced instruction set computers (RISC), application specific integrated circuits, and the like. Although shown with one CPU <b>104</b>, processor system <b>100</b> may alternatively include multiple processing units.

[0023] The CPU <b>104</b> may be coupled to a bus controller <b>102</b> by way of a CPU bus <b>108</b>. The bus controller <b>102</b> includes a memory controller <b>106</b> integrated therein, though the memory controller <b>106</b> may be external to the bus controller <b>102</b>. The memory controller <b>106</b> provides an interface for access by the CPU <b>104</b> or other devices to system memory <b>110</b> via memory bus <b>112</b>. In one embodiment, the system memory <b>110</b> includes synchronous dynamic random access memory (SDRAM). System memory <b>110</b> may optionally include any additional or alternative high speed memory device or memory circuitry. The bus controller <b>102</b> is coupled to a system bus <b>114</b> that may be a peripheral component interconnect (PCI) bus, Industry Standard Architecture (ISA) bus, etc. Coupled to the system bus <b>114</b> are a graphics engine or a video controller <b>118</b>, a mass storage device <b>126</b>, a communication interface device <b>128</b>, and one or more input/output (I/O) devices <b>134</b>. The video memory <b>120</b> is used to contain display data for displaying information on the display screen <b>124</b>. In another embodiment, the video controller <b>118</b> is coupled to the CPU <b>104</b> through an Advanced Graphics Port (AGP) bus.

[0024] The mass storage device <b>126</b> includes (but is not limited to) a hard disk, floppy disk, CD-ROM, DVD-ROM, tape, high density floppy, high capacity removable media, low capacity removable media, solid state memory device, etc., and combinations thereof. The mass storage device <b>126</b> may include any other mass storage medium. The communication interface device <b>128</b> may include a network card, a modem interface, etc. for accessing network <b>130</b> via communications link <b>132</b>. The I/O devices <b>134</b> may include a keyboard, mouse, audio/sound card, printer, and the like. The I/O devices <b>134</b> may also include the specialized display circuits and input circuits of an embedded system.

[0025] As is familiar to those skilled in the art, the processor system <b>100</b> may further include an operating system (OS) and at least one application program, which in one embodiment, are loaded into system memory <b>110</b> from mass storage device <b>126</b> and launched after POST. The OS may be any type of OS including, but not limited or restricted to, DOS, Windows™ (e.g., Windows 95™, Windows <b>98</b>™, Windows 2000™, Windows XP™, Windows NT™, Windows NT Embedded™), Unix, Linux, OS/2, OS/9, Xenix, VxWorks, etc. The operating system is a set of one or more programs which control the processor system's operation and the allocation of resources. The application program is a set of one or more software programs that performs a task desired by the user.

[0026] In one embodiment, processor system <b>110</b> is an embedded system, such as an application card, network appliance or other consumer product. FIG. 2 illustrates one embodiment of processor system <b>100</b> when implemented as an embedded system. In this embodiment, CPU <b>104</b>, system memory <b>110</b>, non-volatile memory <b>150</b>, communication interface <b>128</b>, and I/O circuits <b>134</b> are connected via system bus <b>114</b>. The non-volatile memory <b>150</b> may be programmable read-only memory (PROM) and may contain the Basic Input/Output System (“BIOS”) for the processor system <b>100</b>. Where processor system <b>100</b> is an embedded system, I/O circuits <b>134</b> will correspond to the particular specialized circuits used by the embedded system. By way of providing non-limiting examples, the I/O circuits <b>134</b> may correspond to the input-output circuitry for a cellular phone, personal digital assistant (“PDA”), or other consumer electronic device using embedded system technology. In addition, communication interface <b>128</b> and/or one or more of the I/O circuits <b>134</b> may be used to provide data to the system memory <b>110</b>. Such data may be loaded from a fixed-medium storage device, such as a floppy or hard disk, or may be received over a communications link connected to network <b>130</b>. It should be appreciated that the network can be a local area network (“LAN”), a wide area network (“WAN”), the Internet, or any other data network.

[0027] In accordance with the practices of persons skilled in the art of computer programming, the invention is described below with reference to symbolic representations of operations that are performed by processor system <b>100</b>, unless indicated otherwise. Such operations are sometimes referred to as being computer-executed. It will be appreciated that operations that are symbolically represented include the manipulation by CPU <b>104</b> of electrical signals representing data bits and the maintenance of data bits at memory locations in system memory <b>110</b>, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to the data bits.

[0028] When implemented in software, the elements of the invention are essentially the code segments to perform the necessary tasks. The program or code segments can be stored in a processor readable medium or transmitted by a computer data signal embodied in a carrier wave over a transmission medium or communication link. The “processor readable medium” may include any medium that can store or transfer information. Examples of the processor readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory or other non-volatile memory, a floppy diskette, a CD-ROM, an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc. The computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc. The code segments may be downloaded via computer networks such as the Internet, Intranet, etc.

[0029]FIG. 3A is a block diagram showing the interaction between the data storage system <b>304</b> and one or more application programs <b>302</b>. In one embodiment, data storage system <b>304</b> is executable software code stored on non-volatile memory <b>150</b>, while in another embodiment data storage system <b>304</b> is stored in system memory <b>110</b>. Similarly, application program <b>302</b> may be stored either in system memory <b>110</b> or non-volatile memory <b>150</b>. Where mass storage <b>126</b> is used, data storage system <b>304</b> and/or application program <b>302</b> may be loaded from the mass storage <b>126</b> into system memory <b>110</b> for execution by CPU <b>104</b>. Alternatively, application program <b>302</b> may be executed remotely from data storage system <b>304</b> and be in communication with data storage system <b>304</b> over network <b>130</b>.

[0030] Where processor system <b>100</b> is an embedded system, application program <b>302</b> is comprised of specialized code for carrying out the specific function of the embedded system. For example, in one embodiment application program <b>302</b> may be an embedded Internet browser or embedded XML processor. Moreover, in the case of an embedded system, application program <b>302</b> and data storage system <b>304</b> may be stored on non-volatile memory, while data source <b>308</b> provides data to system memory <b>110</b> to be operated on by data storage system <b>304</b> and/or application program <b>302</b>.

[0031] System memory <b>110</b> and/or non-volatile memory <b>150</b> may further be used to store operating system <b>306</b> and optional API programs <b>310</b>, where optional APIs <b>310</b> are used to perform further processing of data received from data source <b>308</b>. It should be appreciated that, in one embodiment, data source <b>308</b> is a serial source, such as a file stored on mass storage <b>126</b> or a data stream received over network <b>130</b>. Similarly, the data provided by the data source <b>308</b> may be any data set capable of being represented in discreet segments and modeled as a series of nodes.

[0032] Moreover, in one embodiment, data storage system <b>304</b> is an Application Programming Interface (“API”) which serves as a processing intermediary between an application program and a data set from data source <b>308</b>. It should further be appreciated that data storage system <b>304</b> may be a portion of another API, or contained within another processing program. In addition, optional APIs <b>310</b> may be used to carry out additional rendering functions, such as those processing operations carried out by Cascading Style Sheets (“CSS”), Extensible Stylesheet Language (“XSL”), and Document Style Semantics and Specification Language (“DSSSL”).

[0033]FIG. 3B illustrates an alternate embodiment in which optional APIs <b>310</b> are not used to further process the data from data source <b>308</b>. Moreover, operating system <b>306</b> is not used, such as may be the case where processor system <b>100</b> is an embedded system. It should further be appreciated that application program <b>302</b> may be stored remotely from data storage system <b>304</b> and/or data source <b>308</b>. In such an embodiment, application program <b>302</b> may interact with the data storage system <b>304</b> over network <b>130</b>. Similarly, data source <b>308</b> may be remote from both data storage system <b>304</b> and/or application program <b>302</b>.

[0034]FIG. 4 is a process diagram of how application program requests are handled by a data storage system, according to one embodiment. Process <b>400</b> begins at block <b>402</b> where data storage system <b>304</b> is initialized, which may, for example, coincide with a power-on function or an initialization sequence from an application program. At block <b>404</b> an application program, such as application program <b>302</b>, issues a request for a reference to the root node of a data set. In one embodiment, the reference is a physical memory address where the node is stored, while in another embodiment the reference is a virtual memory address. It should be appreciated that the reference may be a table index, an associative memory address, or any other means of identifying a storage location for the node sought. It should further be appreciated that the initialization activity of block <b>402</b> may coincide with the request operation of block <b>404</b>.

[0035] In response to this request, at block <b>406</b>, the data storage system <b>304</b> may initialize internal data, such as any local variables or similar operating parameters. Where a data set is being sent via a communications stream, the data storage system <b>304</b> may also process the data input stream and allocate node storage as needed. Finally, a reference is returned to the application program <b>302</b> by the data storage system <b>304</b>, according to one embodiment.

[0036] After receipt of a reference for the root node, the application program <b>302</b> may then request additional nodes at block <b>408</b>. Data storage system <b>304</b>, at decision block <b>410</b>, makes a determination as to whether the additional node requested by the application program <b>302</b> at block <b>410</b> is a request for a child, sibling or parent node. In one embodiment, this request is in the form of a navigation function call. As is described in more detail below with reference to FIG. 7, the application program <b>302</b> may access specific data in a data set by issuing a series of navigation function calls which result in the data storage system <b>304</b> returning one or more references to one or more particular nodes.

[0037] Upon receiving a navigation function call, such as a request for a reference to a child, sibling or parent node, the data storage system <b>304</b> at block <b>412</b> processes the data from the data source <b>308</b> as needed to respond to the request. In one embodiment, the data storage system <b>304</b> also allocates node storage in system memory <b>110</b> and releases any previously de-allocated nodes to free any additional needed memory. Thereafter, the data storage system <b>304</b> returns one or more references to the node(s) requested, according to one embodiment. Thereafter, application program <b>302</b> has access to the nodes for which it has received references.

[0038] If, however, the request from the application program <b>302</b> was not a request for a node, process <b>400</b> moves to decision block <b>414</b> where a determination is made as to whether the request was to de-allocate a previously requested node. If so, this request is processed at block <b>416</b> and the node in question is de-allocated.

[0039] Where the request is determined to not be a node de-allocation request, process <b>400</b> moved to decision block <b>418</b> where a determination is made as to whether or not the request was a request to de-allocate a subtree. In one embodiment, a request to de-allocate a subtree would be a request to de-allocate a particular node and all of its descendants.

[0040] Finally, the request from the application program <b>302</b> may be a request to exit or terminate the data storage system <b>304</b>, the determination of which is made at decision block <b>422</b>.

[0041] As discussed above, the data storage system <b>304</b> allocates system memory for nodes and returns references to the corresponding memory locations in response to application program <b>302</b> node requests. This process creates a system memory usage state. One such memory usage state is depicted in FIG. 5A. In the memory usage state of FIG. 5A, an application program <b>302</b> has made a root node request, such as was previously discussed in regards to block <b>404</b> of process <b>400</b>. In response, system memory was allocated to the root node <b>504</b> and a corresponding reference returned to the application program <b>302</b>. Moreover, in this embodiment, a subsequent request was made by the application program <b>302</b> for a child node <b>506</b> of the root node <b>504</b>. Again, system memory was allocated and a reference returned. At some point thereafter additional requests were made for nodes <b>508</b> and <b>510</b>. The requests, or navigation functions calls, may have been in the form of two child node calls, or may have been in the form of one child node call, follow by a sibling call. In either event, system memory was allocated for nodes <b>508</b> and <b>510</b> and the corresponding references returned to the application program <b>302</b>.

[0042] Referring now to FIG. 5B, in which a memory usage state is depicted where the data storage system <b>304</b> has pre-fetched nodes <b>514</b> and <b>516</b>. Pre-fetched nodes are those nodes for which memory has been allocated, but for which no application program <b>302</b> request has been issued and no reference returned. To identify the fact that nodes <b>514</b> and <b>516</b> are not visible to the application program <b>302</b>, they are depicted in hatching in FIG. 5B. Similarly, for FIGS. <b>5</b>A-<b>5</b>E nodes depicted in non-hatched boxes are visible to the application program <b>302</b>, while nodes depicted in hatched boxes are not.

[0043]FIG. 5C illustrates the memory usage state where the application program <b>302</b> has requested additional nodes <b>514</b> and <b>516</b>. In response, references are returned to the application program <b>302</b> indicating their location in system memory. Moreover, nodes <b>514</b> and <b>516</b> are no longer depicted in hatching to indicate that they are now visible to the application program <b>302</b>.

[0044]FIG. 5D is a memory usage state where the application program <b>302</b> has further requested that node <b>508</b> be de-allocated. Once a node is de-allocated by the application program <b>302</b>, it is no longer visible to the application program <b>302</b>. However, in the embodiment of FIG. 5D, node <b>508</b> continues to have memory allocated to it, even after the application program <b>302</b> has de-allocated it. Whereas in FIG. 5E, the data storage system <b>304</b> has chosen to discard de-allocated node <b>508</b>. In one embodiment, data storage system <b>304</b> keeps de-allocated node <b>508</b> in memory until memory constraints require that it be discarded. In another embodiment, de-allocated node <b>508</b> is discarded upon being de-allocated by the application program <b>302</b>, regardless of available memory.

[0045] Referring now to FIG. 6, the various node processing states and transitions are depicted. In particular, a node may be described as any one of the following: not yet processed, pre-fetched, active, de-allocated, and discarded.

[0046] As shown in FIG. 6, node state <b>602</b> corresponds with a node which has yet to be processed by a data storage system. Node state <b>604</b> corresponds with a node which has been read into system memory <b>110</b> by a data storage system <b>304</b>, but not yet requested by the application program. Thus, in this state, the node would not be visible to the application program, according to one embodiment. Node state <b>606</b> relates to a node that has been loaded into memory, and for which a reference has been returned to the application program. Node state <b>608</b> relates to a node which the application program has indicated it no longer needs, but which still resides in system memory <b>110</b>. Finally, node state <b>610</b> corresponds to a node which has been removed from memory.

[0047] Nodes transition through node states <b>602</b>-<b>610</b> under varying circumstances. In particular, node transition <b>612</b>, which takes a node from node state <b>602</b> to node state <b>604</b>, may occur when the data storage system determines that sufficient memory is available to pre-fetch the node into memory. In one embodiment, nodes are pre-fetched based on memory availability, while in another embodiment nodes are pre-fetched based, at least in part, on an application program's request patterns. It should be appreciated that such pre-fetching may be done to improve system efficiency and/or system response time.

[0048] A node may enter node state <b>606</b> (i.e., active state) by either node transition <b>614</b> or node transition <b>616</b>. Node transition <b>614</b> occurs when an application program issues a request for node which has already been pre-fetched. In this case, the data storage system simply has to return a reference to the application program for the pre-fetched node already in memory. Alternatively, node transition <b>616</b> also takes a node to an active state and occurs when an application program requests a node which has yet to be processed. In this latter case, the data storage system allocates memory for the node and, when memory limitations require, releases one or more nodes that have been de-allocated, according to one embodiment. Thereafter, a reference may be returned to the application program for the now-active node.

[0049] Node transition <b>618</b>, which takes a node from an active state (node state <b>606</b>) to a de-allocated state (node state <b>608</b>), occurs when the data storage system receives a de-allocation request from the application program. However, the data storage system continues to hold the node in memory.

[0050] Node state <b>610</b> may be achieved through node transition <b>620</b> or node transition <b>622</b>. In the case of node transition <b>620</b>, the data storage system receives a de-allocation request by the application program and decides to immediately discard the node, thereby freeing up previously occupied memory. Unlike node state <b>608</b>, in which the node remains in memory, the data storage system may determine that the node should be immediately discarded due, for example, to a lack of available memory.

[0051] Another route to node state <b>610</b> is through node transition <b>622</b>. In this case, the data storage system chooses to remove from memory a node which had been previously de-allocated. Node transition <b>622</b> may occur as memory limitations require.

[0052] Two other ways a node may achieve node state <b>606</b> is through node transition <b>624</b> and <b>626</b>. In the case of node transition <b>624</b>, an application program issues a request for a node which it had previously ordered de-allocated. In this case, the node is already in memory and the data storage system has only to return a reference to that location. Alternatively, node transition <b>626</b> occurs when an application requests access to a node which had been both de-allocated and discarded. In this case, memory must be re-allocated for the node and a corresponding reference returned to the application program.

[0053] Referring now to FIG. 7, in which navigation function calls <b>702</b>-<b>718</b> are depicted. Navigation function calls are invoked in response to a request from an application program, such as application program <b>302</b>. Navigation function calls return a reference to a desired node and may be invoked through any programming method that supports subroutine, function or method calls. By way of non-limiting examples, navigation function calls <b>702</b>-<b>718</b> may be invoked using programming code in C, Basic, C++, Java, or scripting languages, such as Bourne Shell or perl. Similarly, function calls <b>702</b>-<b>718</b> may be remotely invoked using such methods as CORBA IDL or Java Remote Method Invocation.

[0054] Referring still to FIG. 7, function call <b>702</b> is a parent node request. Function call <b>704</b> corresponds to a next-sibling-node request, while function call <b>706</b> is a previous-sibling-node request. Function call <b>708</b> is a request to find the first child, and function call <b>710</b> is a parent request, as was function call <b>702</b>. Function call <b>712</b> is a request for the last child of a node. As with function calls <b>704</b> and <b>706</b>, function calls <b>714</b> and <b>716</b> correspond to a next-sibling and previous-sibling request, respectively.

[0055] It should be appreciated that other navigation function calls are possible, such as grandparent- and grandchild-node requests. Similarly, cousin node requests are possible, as is any other node relationship describable in familial terms or otherwise. In another embodiment, functions call may be based on application-specific relationships. By way of non-limiting examples, such relationships may include “is an example of,” “has the property of,” or “depends on.” In a relational database, each row of a table may represent a node, where values of columns in rows are used as links to rows in other tables, according to one embodiment.

[0056] In another embodiment, nodes may be represented by unique tags, in which an application program issues requests for nodes having particular tags and the data storage system returns a reference to that tag.

[0057] While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other modifications may occur to those ordinarily skilled in the art.