CROSS-REFERENCE TO RELATED APPLICATIONS

The co-pending U.S. Patent Application Ser. No. 09/406,196, filed on the same date as this application by the same inventor.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not applicable.

REFERENCE TO A MICROFICHE APPENDIX

Not applicable.

BACKGROUND OF THE INVENTION

The invention relates to the processing and presentation of digital data that is dynamic in nature within a retrieval and processing environment that enforces control and monitors accesses made of the environment. By dynamic in nature, it is meant that the content and format of the digital data is not known until the access is received. By environment, it is meant that there exists a computer system repository of digital data wherein there are systems and methods to control and monitor digital data retrieval maintained by the repository.

The present invention is an extension of the systems and methods described by the application listed in the cross reference and as such, numerous details regarding the basis on which the present invention operates are described by that application.

Within a computer repository environment that allows for the controlled and monitored access of data contained within the repository, the format of such accesses can be qualified into three, general categories. These categories are: an access format that employs a fixed syntax; an access format that employs a fixed syntax that allows for the selection of optional parameters; and, an access format that is variable in syntax. Within this classification, the functional characteristic of the access type can be further qualified into two categories of logical operation. These categories are: requesting data held by or adding data to the repository using criteria defined by the repository; and, requesting data held by or adding data to the repository using criteria defined by the requestor.

Within the application listed in the cross-reference, the systems and methods of the first two access formats and the first category of logical operation within a controlled access repository are described. The present invention adds the capability to provide the functionality of the third access format and the second category of logical operation.

BRIEF SUMMARY OF THE INVENTION

Systems and methods are described for controlling the access, assemblage and presentation of, data maintained in a computer system repository using an access format that is variable in syntax and qualified by access criteria specified by the requestor. The present invention has particular application to computer based servers that store or maintain data with varying permission requirements and provide access to such data to a plurality of requesters. The present invention overcomes the deficiencies of prior schemes, which are described by the related application listed in the cross-reference, attempting to process requestor criteria in variable formats. This is achieved by allowing the repository designer to create one or more rule sets, which are utilized by the repository, in interpreting criteria and formats supplied by the requestor at the time of the access. The repository designer creates a single rule set by constructing a file denoted herein as a notational fragment. Using the functionality provided by the notational fragment, it becomes possible to process and assemble requests and responses dynamically into presentations or storage organizations that have not been specifically pre-described. These dynamics allow the repository designer to maintain control over content held by the repository in the event a requestor provides processing criteria or formats whose specific behavior cannot be anticipated or accommodated by the set of criteria or formats defined by the repository.

The invention implements a notational fragment using the concept of an interface set. The interface set is a collection of symbols that identify instructions available to the repository. The behavior of these instructions during the operation of the repository is variable; depending on the format and criteria of the access supplied by a client or other prior art system. The interface set is novel in that it permits the repository to interact with a client or a prior art system that is not necessarily bounded by the restraints imposed on the repository by the designer. In this manner, unbounded accesses and methods can be incorporated under the control mechanisms established for the repository without requiring modification to such accesses or methods.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING

FIG. 1 is a block diagram illustrating an exemplary environment used by the present invention. The relationships existing between data structures of the present invention and the systems and methods of the cross-referenced application are shown.

FIG. 2 is a block diagram depicting symbols that belong to the First Base Set (FBSS).

FIG. 3 is a block diagram of the major components of a Query Template Construct (QTC) file.

FIG. 4A is a block diagram illustrating the major components of a notational type fragment. Shown is the relationship to a QTC file; and, systems and methods of the cross-referenced application when input is accepted from an access made of the repository.

FIG. 4B is a block diagram illustrating the major components of a notational type fragment. Shown is the relationship to a QTC file; and, systems and methods of the cross-referenced application when content is obtained from a datasource using a record format.

FIG. 4C is a block diagram illustrating the major components of a notational type fragment. Shown is the relationship to a QTC file; and, systems and methods of the cross-referenced application when output is obtained from a datasource in statement format.

FIG. 5 is a block diagram illustrating how parameter values of symbols contained within a notational type fragment are resolved to values contained in systems and methods of the cross-referenced application.

FIG. 6 is a diagram depicting the three general forms of a notational type fragment, each showing exemplary symbol use.

FIG. 7 is a block diagram illustrating the relationship existing between the annotation tool, data structures of the present invention; and, values obtained from s stems and methods of the cross-referenced application.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description of the systems and methods of the present invention, numerous specific details of an exemplary embodiment are set forth in order to provide a through understanding of the systems and methods of the present invention. It will be obvious to those skilled in the art to which this invention pertains that the present invention may be practiced without these specific details. In other instances well-known methods, procedures, components and circuits have not been described in detail to avoid unnecessarily obscuring aspects of the present invention.

Within the systems described by the cross-referenced application for controlling access to data in a repository, content that is bounded by the methods of those systems is divided into groups, each group represented by a file denoted as a fragment. The systems and methods of the cross-referenced application qualify fragments by type, each type having specific properties of structure and operational behavior. In this embodiment of the present invention, a description of a new fragment type is provided. This fragment type is denoted as a notational type fragment. A notational type fragment allows for the creation of any fragment type described by the cross-referenced application with the added capability of being able to substitute data occurring within fragment content, with alternates. These substitute values are not known at the time the notational fragment is created.

With regard to FIG. 1, an exemplary relationship of the method and process of a notational type fragment 100 to the DAC 101 and fragment types 102 is depicted. The DAC 101 is a process described by the cross-referenced application. If the argument value 103 indicates a notational type fragment 100, the form module 104 component of the DAC 101 invokes a discrete process denoted as the interpreter 105. The interpreter 105 is defined by and novel to this preferred embodiment of the current invention. The form module 104 also accepts a second input argument 106 that conveys the level of privilege 107 assigned to the use of the notational type fragment 100. Upon completion of its process and method, the interpreter 105 will return a result in one of two formats. One format represents the structure of a fragment 102 and the second format, describing a delivery file 108. Both structures are described by the cross-referenced application.

Inputs 103, 106 received by the form module 104 are supplied to the interpreter 105 when it is invoked. The form module 104 supplies an additional input argument 110 that identifies it. If the interpreter 105 does not recognize the identifier 110 by comparing it to entries in a list exclusive to the interpreter 105, the interpreter 105 returns without producing a result 102, 108. The interpreter 105 obtains a list of valid identifiers from the repository designer through a user interface, such a list being provided before the first invocation call of the interpreter 105 by the form module 104. The method of the present invention is not dependent on the value assigned to an identifier 110.

The output created by the interpreter 105 depends on the appearance order and interpretation of symbols unique to the coding syntax of a notational type fragment 100. This coding syntax defines a symbol as being a finite character sequence, the set of character sequences denoted herein as the interface set. The interface set is composed of one or more base sets, with each base set being uniquely enumerated. In this embodiment of the present invention, symbols contained within one base set are prohibited from appearing as symbols in another base set. The symbols 201-209 shown in FIG. 2 are members of the first base set (FBS) 200. The FBS 200 is enumerated as one (1) in this embodiment of the present, invention. The FBS 200 is an exemplary subset of the interface set and defines what is minimally required to implement a notational type fragment 100 using the interface set.

Each FBS symbol 201-209 is uniquely associated with an instruction sequence. When an FBS symbol 201-209 is recognized, the interpreter 105 fetches the particular instruction sequence associated with that symbol and executes it. In this preferred embodiment of the present invention, an instruction sequence is a software function, suitable for run-time invocation on the system on which the DAC 101 and the interpreter 105 execute.

The interpreter 105 is additionally capable of recognizing a second symbol set as input. These symbols are finite character sequences and reside within a file construct novel to the present invention. This file is not a fragment 100,102 and is denoted as a query template construct (QTC, pronounced as cutesy). When the interpreter 105 is executing in conjunction with the DAC 101, the interpreter 105 expects to find files of this type co-located with content that is controlled and monitored by the DAC 101. An exemplary QTC file 300 and its content are depicted in FIG. 3. The symbols contained within a QTC 300 represent header labels 301, record declarations 302, data field markers 309; and, one or more statements 303. In a QTC file 300, the interpreter 105 accepts symbols coded in language syntax required by the datasource identified in the SOURCE symbol 202. Symbols that represent language syntax required by the datasource do not resolve to instruction sequences used by the interpreter 105. A header label 301 separates the content of the QTC 300 into sections and provides for identification of the sections. A section may be either a record declaration 302 or a statement 303. If a header label 301 identifies a section containing a record declaration 302, the value of the record name 304 field within the header label 301 must correspond to a data origin 305 identified within a statement 303 occurring within the same QTC file 300. If the header label 301 identifies a section containing a statement 303, the statement identity 306 equates to a unique, positive integer by which the statement 303 is identified. Additionally, header labels 301 that identify sections containing statements 303 use a flag value 307 to indicate if the statement 303 should be associated with a section containing a record declaration 302. If this condition is indicated, the statement 303 is interpreted as returning a result from the datasource whose format will match the description declared within the section containing the referenced record declaration 302. If the condition is not indicated, the statement 303 must include in its syntax, all record fields required of the origin 305 that will be referenced by executing FIELD symbols 206 contained with the notational type fragment 100 that has a reference to the QTC file 300. In this preferred embodiment of the current invention, a statement 303 is written using the syntax of the Structured Query Language (SQL), which exists as prior art and is a well-known method for expressing data requests.

A record declaration 302 provides a description of a record that is valid for use with the datasource. The declaration 302 is a listing by name, of the individual fields 308 that structurally compose a single, exemplary record returned or accepted by the datasource using the origin 305 identified by the record name 304. Record field 308 names used within a declaration 302 must be recognizable by the datasource as being valid for the origin 305 to which they are associated and, must be listed in the order in which the origin 305 represents them. A datasource is not restricted to returning records one at a time. The set of one or more records returned by a datasource is denoted as a record set.

A data field marker 309 is a syntactical construct used to facilitate the mapping of fields 308 to locations within fragments 102. A data field marker 309 delineates the location within a fragment 102 at which a value substitution will occur as a result of interaction with the datasource. In this embodiment of the present invention, a data field marker 309 is not valid for use within a record declaration 302.

With respect to FIG. 2, the method of each instruction sequence associated with symbols of the FBS 200 is further explained. The RESULT symbol 201 identifies to the interpreter 105 the type of result 102, 108 that is to be created and must be the first declaration within a notational type fragment 100. The TYPE parameter 210 contains one of two values. One value indicates that a fragment 102 type will be created, the other, to indicate a delivery, file 108 type output. The methods of the present invention do not guarantee that all, possible notational type fragment 100 constructs will generate a valid result 102, 108. In this embodiment of the present invention, by valid, it is meant that the result 102, 108 has a content composed of HTML that is consistent with the intended result 102, 108. In this preferred embodiment of the present invention, the methods of the interpreter 105 guarantee that individual HTML tags created by the interpreter 105 and written to a result 102, 108 will be syntactically correct. The context scope of a RESULT symbol 201 is to the file end of the notational type fragment 100.

The SOURCE symbol 202 identifies to the interpreter 105 a prior art or well-known method with which the interpreter 105 will exchange data. This prior art method is denoted herein as the datasource and is identified by the value of the NAME parameter 211. In this preferred embodiment of the current invention, this prior art method is a process that conforms to the Open Database Connectivity (ODBC) protocol, which is a well known, de facto standard method for exchanging data. Use of the SOURCE symbol 202 within a notational type fragment 100 is optional, however, only one SOURCE symbol 202 is allowed per notational type fragment 100. If used, the SOURCE symbol 202 must follow the RESULT symbol 201 with no intervening symbol declarations. The context scope of a SOURCE symbol 202 is to the file end of the notational type fragment 100.

With respect to FIGS. 2 and 3, the GROUP symbol 203 identifies the origin 305 and processing context of a record set returned by a datasource. The ID parameter 221 contains a value that assigns a unique identity to the GROUP symbol 203. In this preferred embodiment of the present invention, this value is expressed as a positive integer. The TAG parameter 222 contains the identity of the origin 305. The value of this parameter 222 must match a record name 304 or be equal to a statement identity 306. If the parameter 222 references a record name 304, the record name 304 must match at least one origin 305 declaration in which the header label 301 for that section has a flag 307 whose value is equal to a specific mnemonic character sequence. In this preferred embodiment of the present invention, this mnemonic is equal to the character sequence RECORD. If the parameter 222 references a statement identity 306, the value of the statement identity flag 307 contained within the header label 301 must specify a value equal to a specific mnemonic character sequence. In this preferred embodiment of the invention, this mnemonic is equal to the character sequence STATEMENT.

FIG. 4A illustrates an exemplary relationship of a GROUP symbol 203 to a record declaration 302. In the instance depicted by FIG. 4A, all FIELD symbols 206 that occur within the context scope of a GROUP symbol 203 must in their CLAUSE parameter 219, reference a statement identity 306 whose associated flag 307 contains the mnemonic character sequence RECORD. In addition, the statement 303 qualified by the header label 301 whose identity 306 is the value of the CLAUSE parameter 219, must reference an origin 305. In this embodiment of the current invention, the explicit value of the origin 305 must be equal to the value of the TAG parameter 222 of the GROUP symbol 203 that has the current scope.

FIG. 4B illustrates an exemplary relationship of a GROUP symbol 203 to a statement 303. In the instance depicted by FIG. 4B, all FIELD symbols 206 that occur within the context scope of a GROUP symbol 203 must in their CLAUSE parameter 219, refer to the statement identity 306 specified by the TAG parameter 222. The identity of the QTC file 300, in which the record declarations 302 or statements 303 appear, is placed as the value of the TEMPLATE parameter 223.

In the instances depicted by FIGS. 4A and 4B, the REF parameter 224 allows for the creation of a logical set whose members are non-contiguous GROUP symbols 203 referencing the same data origin 305. In this preferred embodiment of the current invention, this is achieved by using the same positive integer as a value of the REF parameter 224 for all GROUP symbols 203 that will be members of a given set.

At least one FETCH 205 or ANS 207 symbol must follow a GROUP symbol 203, themselves; followed by one or more FIELD 206 symbols. A GROUP symbol 203 may appear anywhere after a SOURCE symbol 202, subject to the placement constraints imposed by other symbols in the interface set. The GROUP symbol 203 establishes a context scope that is terminated by a subsequent GROUP 203 or QUERY 204 symbol, the end of a QUERY symbol 204 context scope marked by an END symbol 209 or, the file end of the notational type fragment 100.

The QUERY symbol 204 provides the repository designer with the capability of constructing dynamic requests for data from the datasource. The ID parameter 213 value uniquely identifies the QUERY symbol 204. In this preferred embodiment of the present invention, this value is a positive integer. The QTC parameter 214 specifies the name of a QTC file 300. When the interpreter 105 is executing, the location of a QTC file 300 is co-location with content that is controlled and monitored by the DAC 101. The SET parameter 215 allows for the logical grouping of non-contiguous QUERY symbols 204 that reference the same origin 305. Additionally, a QUERY symbol 204 cannot appear in a notational type fragment 100 without a FETCH symbol 205 appearing immediately after it and a SOURCE symbol 202 being declared at some point before it. A QUERY symbol 204 establishes a context scope that is terminated by an END symbol 209 or the file end of the notational type fragment 100.

The FETCH symbol 205 is used to identify content that will be retrieved when the notational type fragment 100 is processed by the interpreter 105. The INDEX parameter 212 is completed with the identifier of the desired content. The order in which FETCH symbols 205 appear is the order in which content will be accessed and processed into a result 102, 108. The permission value 107 will be applied to all content retrieved using the INDEX parameter 212. In this preferred embodiment of the present invention, it is not valid to nest HTML form declarations within content using multiple FETCH symbols 205 although it is permissible to include multiple HTML form declarations sequentially. A FETCH symbol 205 establishes a context scope that is, terminated by a QUERY 204, GROUP 203, END 209 or FETCH 205 symbol or, the file end of the notational type fragment 100.

The FIELD symbol 206 has two distinct applications within a notational type fragment 100. The first, is within the scope of a QUERY symbol 204, in which the FIELD symbol 206 provides the means to associate data fields in an HTML form with data field markers 309 contained within a statement 303. In its second application it appears within the scope of a GROUP symbol 203 declaration. In this instance, the FIELD symbol 206 provides for content control of data delivered from a datasource.

In the first context, illustrated by an exemplary depiction in FIG. 4C, the PRIVILEGE parameter 216 is ignored. In this context, the DAC 101 provides permission requirements by allowing the interpreter 105 access to permission information. This access is in the form of shared data resources and becomes active when the interpreter 105 makes a request for it. In this preferred embodiment of the present invention, the interpreter 105 cannot alter the permission values shared by the DAC 101. The format of the permission values shared by the DAC 101 is described by the cross-referenced application. Referencing content by processing FETCH 205 and ANS symbols 207 causes a lookup and validation of permission. The LABEL parameter 218 identifies a field 400 occurring within content referenced by the ANS 207 that has scope. This field 400 contains the source value. In this preferred embodiment of the current invention, this field 400 is one that permits data entry as described by the syntax of HTML.

The CLAUSE parameter 219 specifies the statement identity 306 of the section containing the desired statement 303. The POS parameter 220 identifies the data field marker 309 within the statement 303 into which the source value 400 will be placed.

In the second context, illustrated by exemplary depictions in FIGS. 4A and 4B, the PRIVILEGE parameter 216 specifies the privilege level required to receive the value of the field 308 returned by the datasource. The repository designer, through a user interface, sets the value of this parameter 216 during the creation of a notational type fragment 100. The value 106 passed as an argument to the interpreter 105 by the form module 104 is used in comparison with this parameter 216 to determine the validity of the permission 107.

Continuing with the description of the second context and with respect to FIGS. 4A and 4B, the LABEL parameter 218 contains the identity of the data field 401 using the value of the data field marker 309. The CLAUSE parameter 219 specifies the identity 306 of the desired statement 303. Lastly, and again within this context, the POS parameter 220 identifies the position of a field within a record returned by the datasource. In the form depicted in FIG. 4A; this value is equivalent to the position of the field 308 within a data declaration 302. In the form depicted by FIG. 4B, this value is equivalent to the position of the field 308 within a statement 303. In both instances and for this preferred embodiment of the present invention, the values are expressed as positive integers. The privilege requirement 216 assigned to a field 308 in a record declaration 302 or statement 303 is applied to all occurrences of the actual field returned by the datasource that are associated with the declared field 308. FIELD symbols 206 are valid only if they appear following an ANS symbol 207. A FIELD symbol 206 does not create a context scope except unto itself.

The ANS symbol 207 identifies a fragment 102. The identity 406 of the desired fragment 102 is used as the value of the BUILD parameter 217. The ANS symbol 207 establishes a context scope that is terminated by a subsequent ANS 207, GROUP 203 FETCH 205 or QUERY 204 symbol, the end of a QUERY symbol 204 context scope marked by an END symbol 209 or, the file end of the notational type fragment 100. Further, the ANS symbol 207 may be used in one of two ways when specified after a GROUP symbol 203. These two methods are depicted by the exemplary declarations illustrated in FIG. 5.

With respect to FIG. 5 and in the first section, when an ANS symbol 207 is used after a GROUP symbol 203 without an intervening FETCH symbol 205, the value of the BUILD parameter 217 may specify the identity 406 of any fragment 102 suitable for use with FIELD symbols 206. By suitable it is meant that the fragment 102 is not a notational type fragment 100. The fragment 102 so identified will be used for all subsequent FIELD symbol 206 processing until the context scope of the ANS 207 or GROUP 203 symbol ends. In the second section, when a FETCH symbol 205 precedes an ANS symbol 207, it establishes a scope in which all ANS symbols 207 within that context must reference a fragment 102 that is an member 500 of the sequence 503 identified by the INDEX parameter 212. As before, any fragments 102 obtained from the sequence 503 must be suitable.

The GET symbol 208 allows the interpreter 105 to include the contents of external files within the result. External files are defined in the cross-referenced application and generally either exist outside the control and monitoring of the DAC 101 or do not require use of a datasource. The NAME parameter 225 fully qualifies the identity of the external file. GET symbols 208 do not influence the processing of other symbols from the interface set with one exception. A GET symbol 208 may not appear between the declarations of a RESULT 201 and a SOURCE 202 symbol. Positioning of external file contents referenced by a GET symbol 208 within the result 102, 108 is determined by the position of the GET symbol 208 within the notational type fragment 100. In this embodiment of the present invention, the external file referenced by a GET symbol 208 may not contain data field markers 309. The GET symbol 208 does not establish a context scope except unto itself.

The END symbol 209 terminates the context scope of a QUERY symbol 204. In this embodiment of the present invention, the context scope of a QUERY symbol 204 must be terminated before another QUERY symbol 204 may be declared.

The interpreter 105 permits three generalized formats of a notational type fragment 100. FIG. 6 is an exemplary depiction of these formats. These formats are denoted herein as non-source 600, query-response 601 and response-only 602. In FIG. 6, FBS symbols 200 are depicted without their parameter lists and this is done for illustration simplicity only. It should not be inferred from the drawing that the generalized formats 600-602 use interface set symbols while failing to include parameters that are a part of the interface set symbol's syntax. Each of these formats in their result 102, 108 form and the data content they reference, are co-located with content that is under the control and monitoring of the DAC 101. The actual content of a notational type fragment 100 or a QTC file 300 is never used as part of a response to a requestor, within the meaning of response and requestor as defined by the cross-referenced application.

In the non-source format 600, the interpreter 105 will allow the inclusion of FETCH 205, ANS 207 and GET 208 symbols that do not reference H form constructs 402 or data fields 401, 403.

In the query-response format 601, and in this embodiment of the current invention, the interpreter 105 requires that a datasource as represented by a QUERY symbol 205, be an element of content that is controlled by the DAC 101. This is accomplished by declaring at least one GROUP symbol 203 within the context scope of the QUERY symbol 204. If multiple GROUP symbols 203 appear, the output produced by processing each symbol is combined to form the result 102,108 in the order the symbols are declared within the notational fragment 100. If multiple QUERY symbols 205 appear within this format, they must appear in a sequential, contiguous order prior to the first occurrence of a GROUP symbol 203.

In the response only format 602, the result 102, 108 is generated by combining the results of each GROUP symbol 203 in the order in which the symbols are declared within the fragment 100.

To create a notational type fragment 100, the repository designer must initially choose those datasources that will be used and the permission levels that will apply to such use. With these decisions made the designer, through a user interface, creates the QTC files 300 necessary to implement the design, assigning each QTC file 300 a unique name. When creating a design page 700, which is a data structure defined by the cross-referenced application, whose constituent fragments 102 will be referenced by a notational type fragment 100, the designer must structure the design page 700 according to one of the general formats 600-602. This means that when disassembled into fragments 102, the content of the design page 700 must correspond to the accepted layout of symbols 201-210 used within the chosen format 600-602. The methods of the present invention do not prohibit the use of existing, disparate design pages in the creation of a notational fragment 100, subject to the rules of interface symbol set usage. In this preferred embodiment of the present invention, all result forms 102, 108 must represent valid HTML in syntax and context before being permitted to be content controlled and monitored by the DAC 101.

With respect to FIG. 7, creation of a notational type fragment 100 is accomplished using a two step process. In the first step, the designer performs a layout and design of a result 102, 108 creating it using the format of a design page 700. All such layouts are processed using the reference tool 701, a system that is described by the cross-referenced application. The reference tool 701 produces the response page entry 501 and jump table 702 for each design page 700. Using the annotation tool 703, which is a standalone set of processes and methods executed on a computer system that is typically not the system utilized by the DAC 101 and the interpreter 105, the identifier of the design page 700, a reference to the response page entry 501 and jump table 702; and, the QTC files 300 are accepted as input. Starting at the reference tool 701 step, this process is repeated for each design page 700.

Through a user interface, the designer must indicate the format 600-602 expected from each set of inputs to the annotation tool 703. With the receipt of this information, the tool 703 creates a temporary list 704, denoted herein as the t-list. Each entry in the list 704 is initially created with three fields. The first field contains the identifier of the original design page 700, the value of the second field is a reference to the response page entry 501, and the third field contains the format 600-602 type value. Entries in the t-list 704 facilitate the method by which the annotation tool 703 relates the format 600-602 type to each response page entry 501.

When creating design pages 700 for use in notational type fragments 100, a designer must account for two further considerations. The first of these pertains to HTML form usage. With respect to FIG. 4A, when an HTML form is specified 402, the designer does not specify the actual object 405 of the reference 404 used by a requestor when the form is executed. Instead, the object 405 is completed using a unique name created by the designer. This name is used in a later step. In this instance, the annotation tool 703 will not update any entry in the substitution list 705 for the reference 404. The substitution list 705 is a data structure described by the cross-referenced application. With respect to FIGS. 4A, 4B and 4C, the second consideration applies to syntax that permits data entry 403 or the placement of data 401. Each such field 401,403 created by the designer must be identified using a name that is unique. A field 401,403 name must be declared in the HTML construct that implements the field 401,403.

In this preferred embodiment of the present invention, the annotation tool 703 will process all non-source formats 600 first, followed by all response-only formats 602 and concluding with all query-response 601 formats. If a particular format has no entry within the t-list 704, the tool 703 proceeds to the next format type 600-602.

For non-source formats 600, the tool 703 prompts the designer through a user interface for the result type 600 and constructs a RESULT symbol 211. For each response page entry 501 identified by an entry in the t-list 704, the tool 703 will generate a FETCH symbol 206 placing the entry index 502 as the value of the INDEX parameter 215. The designer then reviews the build code sequence 503 of the selected entry 501. Through a user interface, the designer indicates to the tool 703 those build codes 500 to be used within the notational type fragment 100. For each build code 500 selected, the tool 703 will generate an ANS symbol 208 placing the identifier of the build code 500 as the value of the BUILD parameter 220. In this preferred embodiment of the present invention, the tool 703 creates a new file into which it writes symbols selected from the FBS 200. This new file will become the notational type fragment 100. By examining a directory list provided to it by the reference tool 701, the annotation tool 703 assigns the file a unique build code 500 identifier. The annotation tool 703 creates a build code 500 value in the same manner as the reference tool 701