Dynamic, hierarchical data exchange system6356920Abstract A computer system provides the ability to construct and edit a Data Definition File (DDF) containing hierarchically related elements of data, some of which are dynamic in that they must execute in order to produce or retrieve data. A client computer system having knowledge of a DDF appropriate for its uses sends a request to a server, which contains or can retrieve the DDF requested by the client. The request contains parameters used by the server to customize the resulting keyed data file for the client's purposes. Upon receipt of the request, the server copies the DDF into a coupled memory, performs requested parameter substitutions, and executes dynamic elements to produce resulting data elements. The process is repeated recursively for all elements of the hierarchical structure, until no dynamic elements remain, then the resulting keyed data file is returned to the client for its uses. Data elements may be derived from a plurality of sources, and these sources may be combined and manipulated using a plurality of data operations, including relational algebra or structured query language, enabling joins and merges between multiple sources and formats. An Authoring System is provided which assists in the construction and validation of DDFs. Claims What is claimed is: Description FIELD OF THE INVENTION
02/27/1999 002
03/01/1999 003
03/02/1999 005
This results in 3 new children for the original element, one for each row returned. Each of the three new elements would contain two generated elements, one containing the date, and one containing the order number. Let's assume now that the original element has a child element. The child element is replicated as a child in each of the 3 generated row-level elements above. The original child element can be executable, and can also refer to the newly generated children, having foreknowledge of what will be generated. In particular, it may be useful to execute an SQL statement that generates ORDER_ITEM elements by referring to the generated NUM field. This SQL statement might look like this: "select NAME, ITEM_NUM from ORDER_ITEMS where ORDER_NUM=%%./NUM". At execution time, %%/NUM is treated as a relative reference to the child element of type NUM. The Value field of this element is retrieved and used in place of "%%./NUM". The query is executed and additional children elements are created, expanding the hierarchy depth. The hierarchy can be endlessly extended with ever-deeper children, each of which are replicated then executed. DDF Parameters In another aspect of a preferred embodiment of the invention, a DDF can define parameters for a Client's use, so that a Client can specify customization for a generated Data File. A DDF that generates customer account data, for example, may define a DDF parameter for customer phone number. The DDF parameter can be defined anywhere, but it is convenient to define a standard location, which we will call the INPUT element. This is an element in the document of Type INPUT, where attributes can be stored as DDF parameters. The input attribute is generally created as a template attribute at the time the DDF is created. For example, the INPUT element of the customer account DDF may contain the attribute PHONE=1112223333. A Client may request the customer account DDF, and specify a parameter substitution "/INPUT.PHONE=7195551212". Assuming the INPUT element is a root-level element, a processing engine would replace the value of the PHONE attribute with "7195551212" prior to executing any elements in the DDF. Execution would proceed, and presumably one or more executable elements would use a replacement operator referring to this input parameter. As an example, an SQL select statement might contain the reference %%/INPUT.PHONE in a where clause, thus selecting data for the appropriate customer. Several shortcuts are possible in parameter references. Input parameters could refer simply to attributes in the INPUT element. Thus, input parameter PHONE=7195551212 is equivalent to "/INPUT.PHONE=7195551212", and the replacement reference %%/INPUT.PHONE can be shortened to %%PHONE. Data File Formatting In another aspect of a preferred embodiment of the invention, after a DDF is fully executed, remaining elements are output using customized formatting options. A system parameter file contains formatting commands for each type of element Style. The formatting occurs by processing each element recursively, and applying the formatting commands specific to the element's Style. Domains Available formatting styles are grouped into Domains. A Style indicator can reside in several Domains, with each Domain defining a different format for the Style. Thus, selecting a Domain specifies the output format of the DDF. A DDF can specify a default Domain for generated Data Files by specifying the Domain in the GEN_TYPE attribute. This attribute is generally in the first element in the document, though it does not need to be. A Client may request a specific output format by setting the GEN_TYPE attribute in a parameter specification. Hierarchical Data Server In another aspect of a preferred embodiment of the invention, a computer system is capable of receiving requests for data files. Each request for a data file includes a reference to a DDF, plus parameters. The Server receives the request, reads the DDF into memory, and performs parameter substitutions for any parameter supplied by the Client. The Server then visits each element in the DDF, first performing replacement for any replacement operation (references preceded by "%%"), then executing the element if possible. Elements are recursively processed. After completion of all execution, processing occurs for formatting and output. All elements are again visited, and output according to formatting commands based on the indicated Style of the element and the DDF's Domain. The fully processed output is then returned to the Client. The Server in this example is called a Hierarchical Data Server, or HDS. Document Definition Authoring System The job of creating DDFs can be very complex in the enterprise environment. To assist in creation and editing of DDF, the present invention specifies a computer system that assists a human in constructing DDFs. This computer system is called a Document Definition Authoring System (hereinafter referred to as Authoring System). FIG. 4a shows a preferred implementation of the Authoring System. FIG. 4a shows the DDF named join.itd. The top window panel shows a graphical tree representation of the document which is constructed using the Microsoft Foundation Classes CTreeCtl class. The elements include an element of Type "XML" that generates an XML header for the file, an Input element that lists the parameters and values for the document, a Database element that defines the data source for all subsequent statements, and a PROBLEM element. The PROBLEM element has two children elements, each containing an SQL select statement. The lower portion of the window shows the same DDF in XML format. This panel is not modifiable. The View menu includes an option, "Expand Expressions", which executes the elements to produce the resulting Data File. The option File/Export performs this function also, storing the results to a file. View/Expand Expressions option produces the results as shown in FIG. 4b. Appropriate commands are supplied to insert new elements at a selected location, edit existing elements, delete elements, and drag and drop elements to new locations. FIG. 4c displays the input form used for creating and editing elements. The Style, Type, Value, and Attributes fields correspond to components of the element as described earlier. The Item field is a synonym (readable label) for the Type, which can be defined in the system parameter file, for example, FIG. 5, lines 202-203. The Settings box displays the Execution Type selection that populates the EXEC attribute, and the Invisible flag, which, when checked, causes the introduction of attribute VISIBLE=NO. The button labeled "File . . . " allows the navigation and selection of a file, whose full path will then be supplied in the Value field. The button labeled "SQL . . . " initiates the display of the helper form in FIG. 4d, which assists in the construction of an SQL statement. Children of an element are established by creating a new element as a child of an existing element. The user first selects the parent element, then selects a menu option to insert a child element. FIG. 4a displays an icon next to each element. This icon is associated with the element Type in the system parameter file, as in FIG. 5, line 202. A preferred embodiment also allows the user to specify an icon that is externally generated, in which case the icon's file name would be specified by the attribute FILENAME in FIG. 5, line 202, instead of an internal ICON_INDEX. A complete set of operations in a preferred embodiment of the invention would include these operations:
Command Available when clicked on Operation
Insert Root Empty space in left panel Create a new root level
Element element
Edit Element Icon Edit the type, value, and
attributes of an element
Delete Element Icon Deletes the selected element
Insert Child Element Icon Create a child of the selected
element
Insert Before Element Icon Create an element, place it
before the selected element.
Insert After Element Icon Create an element, place it
after the selected element.
Indent Element Icon Move the selected element to
make it a child of the element
directly above the selected
element
Outdent Element Icon Move the selected element,
removing it as a child element
and making it a sibling of its
previous parent.
Drag & Drop Click and Drag an Element Repositions the element to a
Icon different location in the tree
XML Support In another aspect of a preferred embodiment of the invention, both the DDF and the Data File follow the syntax rules of Extensible Markup Language (XML), a standard published by the World Wide Web Consortium. Elements in the XML document representing a DDF can be static or dynamic. When a client requests a document from a server, it references the appropriate DDF that is accessible from the Server, and passes the server any appropriate input parameters. The DDF is copied, parameter substitutions applied, and elements are executed to generate or retrieve the data for each element. Some of these elements may be XML links to other XML documents and/or elements. These external XML components may themselves be either static or dynamic, and are treated appropriately before incorporation into the resulting DF. In another aspect of a preferred embodiment of the invention, one of the Hierarchical Data Server's defined Domains is XML. Consistent with the formatting features mentioned previously, the Data Server can thus dynamically generate XML files on behalf of clients. Clients using the XML domain can exploit the rapidly growing number of software tools designed to work with XML. For example, XML parsers are available free of charge on the World Wide Web, and the W3C Document Object Model, a software component also widely available and built into the Microsoft Internet Explorer version 5.0, enable a Client to navigate through the returned Data File using industry standard software. The ability to use a free parser and free or inexpensive DOM leads to drastically reduced development costs for clients, as the Parsing Code 6 component of an interface no longer needs to be developed. In another aspect of a preferred embodiment of the invention, the Hierarchical Data Server provides the ability to interface to a plurality of dynamic data source types. As examples, the following dynamic data source types are supported: 1. Open Database Connectivity (ODBC) data sources for any ODBC-compliant data source supporting SQL; 2. Microsoft Data Access Objects and Microsoft JET engine, supporting SQL interfaces; 3. Microsoft ActiveX Data Objects, supporting a multitude of data sources; 4. Command line program interface that allows a DDF element to run any program and read and format the result into the Data File. Each type of dynamic data source is known by an indicator called an EXEC type. The available EXEC types are listed in the system parameter file. When the HDS processes a DDF, each element that specifies an EXEC type as an attribute is executed using the specified EXEC type. In addition, new dynamic data sources can be defined, and code to implement the interface imported into the Hierarchical Data Server using dynamically loaded code modules. A corresponding EXEC type must be appropriately placed in the system parameter file, and the DDF element data required in the interface must be specified so that the correct information can be passed to the Request Code 4 component. In this way, an enterprise can implement the Request Code 4 and Server Description Code 6 a single time in the Hierarchical Data Server. All clients needing data from a server requiring the new interface would request the data from the Hierarchical Data Server and receive the resulting data in any supported format. Thus, clients in the enterprise use a standard Parser Code 5 component instead of writing new interface code components specific to their interface with the Server in question. The ability of the Hierarchical Data Server to support new interfaces should not be understated. Revisiting the example of FIG. 3, the Parser Code 5 is now identical for each Client, and the Request Code 4 and Server Description Code 6 is moved to the Hierarchical Data Server and is no longer developed in the Client. Thus, Request Code 4 and Server Description Code 6 is developed once for each Server for a total of 8 components, plus the Parser Code 5 is developed once for both clients for a total of 8 developed components, a dramatic savings over the 22 development components in alternate strategies. In another aspect of a preferred embodiment of the invention, a Client can request a complex Data File from the Hierarchical Data Server in which a plurality of dynamic elements reference data generated data within the Data File. For example, DDF element A may instruct the HDS to generate a list of rows from a DBMS, which the HDS incorporates as Data File elements. DDF element B may reference the said Data File elements, using selected elements as key parameters in its generation step. Generated data from one DDF element. Filtering Data File Output In another aspect of a preferred embodiment of the invention, certain attributes in the DDF element control whether the resulting elements are included in the output Data File. The attribute "INCLUDE", when set to "NO", directs the HDS to exclude the element from the generated Data File. The element is neither executed nor formatted. Generally, the attribute would not be set to the literal "NO" in the DDF. Instead, it would be set to a replacement reference that would be substituted based on a Client-supplied parameter. For example, an input parameter named "DETAIL" might be referenced by an executable element in the DDF by including the attribute "INCLUDE=%%DETAlL". A Client wishing the element to be executed and included would pass the parameter "DETAIL=YES". A Client wishing to exclude the element would pass the parameter "DETAIL=NO". In addition, the attributes SWITCH and CASE allow clients to select one of a number of elements to execute and include in the output. When the HDS processes an element with attribute CASE, it checks the attribute's value and compares it with the value of the attribute SWITCH in the element's parent. If the values match, the element is executed and included. Otherwise, it is discarded as in the case of attribute "INCLUDE=NO". The value of the SWITCH attribute would likely be a replacement reference, so that a Client could select the desired element to execute by setting an input parameter, similar to the INCLUDE example above. The VISIBLE attribute controls whether an element is included in the output after execution. A value of VISIBLE=NO directs the HDS to execute the element as normal, yet do not display the resulting element. Children of the element, whether generated via execution or not, are not affected by this attribute. Multi-threaded Execution In another aspect of a preferred embodiment of the invention, the execution of elements is carried out in multiple threads. For an element having executable children, setting an attribute CHILDREN_THREADS=YES directs the HDS to spawn a new thread for each child. Each child executes to completion in the thread. The HDS waits for all children threads to execute prior to finishing processing for the parent. Joins In another aspect of a preferred embodiment of the invention, two or more elements can be joined together in the same sense as a database join. When an element specifies the attribute JOIN=YES, or when the predefined element Type is JOIN, the children of the element are joined together. When a Join is specified, children elements in Set/Row/Column format will be joined together into a single set, which replaces this element. Set/Row/Column format is described as follows: Using the Authoring System, document elements are often generated from database sources. Since databases generally return rows of data, the format of elements are very consistent. A database query returns a set of rows, and each row contains a number of columns. When retrieved into an InfoTree Document, this consistent format is called the Set/Row/Column format. In XML format, an example looks like this: <ORDERS_COMPLETE> <ORDER> <ORD_CD>0000000026</> <SSN>111223333</> <SALES_REP> <FlRST>Kirstan</> <LAST>Vandersluis</> </> </> <ORDER> <ORD_CD>0000000044</> <SSN>111223333</> <SALES_REP> <FIRST>Kirstan</> <LAST>Vandersluis</> </> </> <ORDER> <ORD_CD>0000000045</> <SSN>111223333</> <SALES_REP> <FIRST>Kirstan</> <LAST>Vandersluis</> </> </> </> The ORDERS_COMPLETE element follows the general sure called Set/Row/Column, which is roughly equivalent to a database table. An InfoTree document can contain many such sets, and in this sense can represent an entire database. InfoTree provides operations on Set elements very similar to SQL commands on database tables. Data from elements with this structure can also be joined (see JOIN_KEY, JOIN_SET, JOIN_LABEL attributes) with each other, or with any other element with a similar structure, namely elements generated from other database tables. The HDS operations on Set/Row/Column structures allow the HDS to manipulate data from many different system, regardless of the native format of the data. Multiple enterprise data sources can provide data that can then be joined, selected, and filtered in a myriad of ways. Note that the Set/Row/Column format is not restricted to a single, simple element at the Column level. As in the case of SALES_REP above, a column element may have subelements, and in fact can be arbitrarily complex. The Join operation references a JOIN_KEY attribute, which specifies the element Type on which to Join. The above example can be joined with another set of element data. For example, assume another element set specifies phone numbers of sales representatives. A portion of the data may look like this: <PHONE_BOOK> <REP> <SSN>111223333</SSN> <PHONE>7195551212</PHONE> </REP> <REP> <SSN>777334444</SSN> <PHONE>3035551212</PHONE> </REP> Specifying JOIN_KEY=SSN directs the HDS to combine the sets into a single set, resulting in the PHONE element being copied into the ORDER set as follows: <ORDERS_COMPLETE> <ORDER> <ORD_CD>0000000026</> <SSN>111223333</> <PHONE>7195551212</PHONE> <SALES_REP> <FIRST>Kirstan</> <LAST>Vandersluis</> </> </> <ORDER> <ORD_CD>0000000044</> <SSN>111223333</> <PHONE>7195551212</PHONE> <SALES_REP> <FIRST>Kirstan</> <LAST>Vandersluis</> </> </> <ORDER> <ORD_CD>0000000045</> <SSN>111223333</> <PHONE>7195551212</PHONE> <SALES_REP> <FIRST>Kirstan</> <LAST>Vandersluis</> </> </> </> The Join operation can be performed on any number of children. For a more detailed specification of the Join Specification, see FIG. 13, Join Code. Element Attributes Many processing commands are controlled by element attributes. The form for an attribute is: ATTRIBUTE=VALUE Where ATTRIBUTE is the name of the attribute from the table below, and VALUE is a string value enclosed in single or double quotes. A list of supported attributes follows:
Attribute Description
EXEC If present, this element is dynamic. This
attribute designates the execution type (SQL,
ActiveX, Join, Shell, ADO). SQL takes an
SQL statement from the Value field and
executes it. The target data source of the SQL
statement must be specified by a
DBDEFINITION element somewhere in the
document. The default DBDEFINITION is the
first instance in the sequence of parent
elements, or any sibling element of a parent.
Alternatively, the DBNAME attribute specifies
the ID of DBDEFINITON element. ActiveX
invokes an ActiveX control to generate data.
Join performs a database Join on the children
elements. Command executes a shell command
to generate data. Shell takes a shell command
as the value, executes it using its stdout as data.
JOIN_LABEL Designates the Type tag to use for resulting
element sets from a Join
JOIN_TYPE Performs either an Inner or Outer join on the
children elements
ROW_TAG The Type tag to use in generated row data for
SQL rows or lines of data generated by a Shell
Command.
COL_TAG The Type tag to use in generated column data
for SQL columns, or token data generated from
a Shell Command.
COL_TAGS A list of Type Tags to be used to tag columns
returned from an SQL statement or for tokens
generated by a Shell Command.
JOIN_KEY The Type tag to look for which defines the
element sets to join. When the Value field of
the appropriately tagged subelements are equal,
the elements are joined to form a single
element in the result set
VISIBLE Determines whether the element is visible in
the resulting document (default is "YES"). If
this is "CONTENT_ONLY", the value of the
element is transferred to the resulting
document, but not the attributes or element type
data.
COL_SEPARATOR For SQL elements, designates a separator
character between columns. If this attribute is
present, the columns do not have their own
start and end tags. The column data is instead
separated by this character. For shell-generated
elements, this character string designates the
separation between tokens, each of which will
become elements. If this is " " (single space),
then parsing removes excess white space
between tokens.
DBTYPE Type of the database: ODBC, DAO (Data
Access Objects), ADO (Active Data Objects),
XML (Extensible Markup Language), ITD
(InfoTree DDF)
DBNAME Reference to an element that defines the data
source. This is the ID of the DBDEFINITON
element defining the data source.
HTML_COL_TAGS Specifies the tags to generate column headings
in an HTML generated table.
COL_LABELS List of labels, separated by `.vertline.`, designating
the
column header for the HTML table.
SORT_BY Designates sorting criteria for a
Set/Row/Column formatted element. Lists the
column tag and optionally whether the sort is
ascending (ASC) or decending (DEC).
Example: SORT_BY="ORDER_CD ASC".
Multiple sort criteria can be applied in order of
significance, by including more than one
SORT_BY attribute.
CHILDREN_THREAD Designates whether children of this element are
expanded in parallel.
SKIP Designates whether this element is skipped. If
"YES", this element is not expanded, and is
treated as invisible. The resulting InfoTree
document behaves as though this element does
not exist.
SWITCH Controls the generation of children elements.
The value of the SWITCH attribute selects the
children elements which are executed. Any
child element with a CASE attribute equal to
the value of the SWITCH element will be
expanded. All others will be skipped, as if the
SKIP attribute is set to YES.
CASE Controls the generation of children elements.
IMPORT Specifies the URL of a file to import into this
element. This element is replaced by the root
designated by the value of this attribute, which
may contain an element reference (separated
by #).
IMPORT_TYPE Specifies the type of resource to import. Values
are XML or ITD
PARSE For Shell command elements, determines
whether the command output is parsed (the
default) according to ROW_TAG (per output
line), COL_TAG or COL_TAGS (per
"column"). If set to "NO", the output of the
shell command is used as the text for the
element. If set to "XML", the internal XML
parser is run with the output of the shell
command, and the output is parsed into DDF
format.
HIDE_VALUE This attribute indicates that the generated
output element will not include the element's
value.
A preferred embodiment of the invention recognizes several special elements Types. These elements, when processed, cause useful effects as described below.
Element Item Element Type Description
Database DBDEFINITION Defines a Data Source to be used in
SQL executions
Input INPUT Defines a list of parameters for the
document. A document generally has
at most one element of this type. A
client requests a document by
specifying the DDF and a
replacement INPUT element. The
supplied INPUT element is used to
replace variables in the document.
Join Children DBJOIN Specifies that children elements in
Set/Row/Column format will be
joined together into a single set,
which replaces this element.
General GENERAL A generic element type that can be
used to house any static or dynamic
attributes, values, and children.
Operation of Invention FIG. 6 shows a flowchart of the HDS portion of the preferred embodiment of the present invention. The HDS begins execution as a computer program by performing a System Initialization step 30 in which the program is loaded and initialized. During this step, the System Parameter file, FIG. 5, is read into memory for use during execution of the HDS. The HDS then awaits and accepts requests 31 from Clients. Communication between Client and Server can occur using any available mechanism, for example HTTP. Requests include a name to uniquely identify the DDF, plus a plurality of parameters appropriate for the DDF, each set according to the needs of the Client. Once the full request is received, the HDS reads the full DDF into memory 32, and performs parameter substitution in memory 33. Each parameter includes a reference to an element component in the DDF, plus a value to replace in the form <reference>=<value>. Parameter substitution is performed in part by using the mechanisms of FIG. 14, Substitution Code. For each parameter, the reference is passed to GetTreeItemComplexPath 410, which returns a pointer to the appropriate element in the DDF. Note that an element is coded as a CTreeItem in the code examples. The pointer, now pointing to the desired element, provides access to the element. If the <reference> includes an attribute name, the attribute with that name in the element in question gets the <value> passed in. If no attribute name is part of the <reference>, the <value> is copied into the Value for the element in question. This process is repeated for each parameter. After parameter substitution, each top-level element in the DDF is processed 34 by a method to be described presently. Recall that a DDF is defined as a list of elements. The current process 34 simply calls the method Process Element 37, FIG. 7, on each element in this list. Once processing is complete, the resulting data is formatted into a data file 35, using a process fully described in FIG. 9. Finally, the resulting Data File is returned to the Client. FIG. 7, Process Elements, describes the method of processing an element 37. First, Reference Substitution is performed 38 by the mechanism described in FIG. 14, Substitution Code. We then check for an IMPORT attribute in the element 39, and if so, we check the value of the Import Type attribute to see if it is XML 40, DDF 41, or some other supported custom type 42. As can be seen in FIG. 7, the element is processed appropriately 45, 46, 47 based on the value of this attribute. If the value indicates an unknown format, we don't import, but instead keep the element as is. We next perform conditional inclusion processing the INCLUDE, SWITCH, and CASE attributes at items 49, 50, 51, 52, and 53. Next, we determine if this element is executable 55 based on the value of the EXEC attribute, in which case we execute it appropriately as described by 56, 57, 58, 59, 61, 62, 63. If the value of the EXEC attribute is SQL 56, we execute the element in the method described by FIG. 11, SQL BuildSubtree, which builds and returns an element hierarchy that then replaces the current element. If the value of the EXEC attribute is COMMAND, we execute the element in the method described by FIG. 13, CMD BuildSubtree, which builds and returns an element hierarchy that then replaces the current element. This method can be extended by integrating other execution types 58 and 63. After execution of the element and replacement with the new element hierarchy, children of the original element are copied to each child of the new hierarchy. The copied children may be executable elements, and can reference the newly generated elements, as long as they have foreknowledge of the element names and structure. Finally, each child of the element, whether it was executed as just described, or not 60, is itself processed using the method of FIG. 8, Process Children. FIG. 8, Process Children, begins by checking whether the children are to be processed by parallel threads 65. If so, a new processing thread is created for each 66. Within the thread, Process Element 37 is called for the child element. Once all threads are running, the thread processing the parent element blocks 68, waiting for all threads to terminate, or until a timeout expires, at which point all child threads are done and we proceed with processing. If children threads are not requested 65, we sequentially call Process Element 37 for each child. Note that for both the multi-threaded and single-threaded cases, we are recursively calling Process Element 37, thus systematically processing our way through the element hierarchy in a depth-first sequence. After all elements are processed 69, we perform post-processing operations. In particular, we check for a Join request 70, and if requested, we join the plurality of children as described in 71. At this point we are done processing an element, and we may optionally remove all elements that have an attribute VISIBLE=NO. If we choose not to remove these elements here, we remove them later in the formatting procedure of FIG. 9. FIG. 9, Format Memory into Data File, first establishes the Domain of the format 76. Note that the Client may have specified the format in a parameter. We next prepare to iterate through the list of top-level elements 77, and for each top-top level element we find 78, call Output Element 79, whose method is described in FIG. 10. If no elements remain, we are done formatting 80. FIG. 10, Output Element, provides the mechanism to format and output the element to the Data File. We begin by determining the Style of the element based on the element's Style indicator and the current Domain. FIG. 5, System Parameter File, shows the format of example Domains and Styles. For example, Line 4 begins the Domain XML, which we will match if the current DDF's GEN_TYPE also is XML. The current element may have a Style of "ELEM", which we will match against the Style of Line 5. Line 6 provides a formatting string. The formatting string is output to the Data File, with special tokens indicated by `%` being replaced by components of the elements. The following substitutions are performed: %T is replaced with the element Type, %V is replaced with the element Value, %A is replaced with the element's attribute list, each attribute constituting a key-value pair, and %C is replaced by the output of the children of this node. Note that here again, we recursively define a mechanism that will process and format elements in a depth-first fashion. In the current example, our format string is "<%T%A>%V%C<?%T>". If our element Type is "ITEM", and we have one attribute NUM=1, and the element Value is "TABLE", the output would be "<ITEM NUM=1>TABLE</ITEM>". FIG. 10 describes this substitution in84, 87, 88, 89, 90, 91, 92, 93, 95, 96, 97, 98, 99, and 100. Custom formats may also be processed as in 85 and 86. Elements that have attribute VISIBLE=NO are not output, but if %C is specified in the format string, the children elements are processed here as usual. FIG. 11, SQL BuildSubtree presents the mechanism for executing an element that has execution type EXEC=SQL. The SQL statement is taken from the element's Value field 103. We then determine how to format the resulting rows 104 and columns 105 in terms of element components. This means we need to determine the Type of the generated elements. Next, we secure the database connection 106 and open the connection 107 if it is not open already. Then we execute the SQL on the connection 108 and begin reading database rows 109. When we get a row 110, we create a new element as described in 106, then process the columns in the row 113 until there are no more. For each column 114, we create a new element, giving the element the Type as described by 115 and the value of the database column 117. We process all columns in the row in this manner until no more columns are available, then move to the next row 116. We process all rows as described above until no more are available, then we return the newly created element hierarchy or subtree 111. FIG. 12, CMD BuildSubtree presents the mechanism for executing a command line program and formatting the results into an element hierarchy. We retrieve the command line program (also called shell program) from the element's Value field. We next check for the attribute PARSE 121, and if present, check if its value is XML 122. In this case, we run the command line program, and feed its output into an XML parser 123, reading the resulting data into DDF format and returning it 124. If the value of the PARSE attribute is something else, we check to see if this is a request to run a custom parser (such as an SGML parser, or any other custom parser) 127, then we run the command line program and feed its output into the custom parser, which reads the resulting data into DDF format 128, which we return 129. If we did not find the PARSE attribute, we proceed with processing the element. We read the formatting commands as described in 125 and 126, which directs us how to create elements, and what the element Types will be. We then execute the command line program 130, and then read lines of data 131 as long as we can get another line. For each line we read, we create a new element as specified in 135, then we determine if we need to create column level elements based on the presence of the COL_TAGS or COL_TAG attributes 136. If not present, we set the new row elements Value to the value of the read line 133, then attempt to get the next line. If COL_TAGS or COL_TAG is present, we parse the line as space or comma delimited columns, creating an element for each as specified in 138, 139, 140, and 141. While the above descriptions contains many specificities, these should not be construed as limitations on the scope of the invention, but rather as an exemplification of one preferred embodiment thereof. Many other variations are possible. Accordingly, the scope of the invention should be determined not by the embodiment illustrated, but by the appended claims and their legal equivalents.
|
Same subclass Same class Consider this |
||||||||||