Apparatus and method for dynamically creating a document6006242Abstract An apparatus and method for dynamically constructing electronic and printable documents and forms. An entity reference is read from a document instance and compared to entity identifiers provided in a catalog containing a plurality of entity identifiers. Each of the entity identifiers in the catalog is associated with an entity resolution process. An inference engine or other entity resolving processor is invoked to effectuate the resolution process associated with a matching entity identifier. The inference engine or entity resolving processor resolves the entity reference to a resolved entity, such as a component of text or graphics to be included in a document. Linking between the document, entity reference, and resolved entity provides for detailed auditing of the entity resolution process. A resolved entity may contain one or more embedded entity references which are similarly resolved. The dynamic document construction methodology may be implemented using a distributed networking approach, or on a stand-alone computer system. A significant advantage of the present invention concerns the re-usability of textual, graphical, and other components, thereby providing for the construction of any arbitrary document type having any arbitrary number of presentation formats. In one embodiment, the inference engine used to resolve entity references is converted to an executable form to enhance portability. A document or form constructed in accordance with the present invention may be published in printed or electronic form, such as in the form of a World Wide Web (Web) page. Claims What is claimed is: Description MICROFICHE APPENDIX
______________________________________
<!ENTITY BSI "Bankers Systems, Inc.">
______________________________________
defines an entity having a name BSI and a value defined as the character string "Bankers Systems, Inc." This representation is considered an instance of an entity declaration, which declares an internal entity. The following declaration, by contrast, declares an external entity:
______________________________________
<!ENTITY ChapTwo SYSTEM "sgmlmkup.txt">.
______________________________________
This declaration defines a system entity having a name ChapTwo and a value defined as the text associated with the system identifier. In this example, the system identifier is the name of an operating system file, sgmlmkup.txt, and the replacement text of the entity is the contents of the file. After an entity has been declared, it may be referenced anywhere within a document. This is accomplished by supplying the entity name prefixed with the ampersand (&) character and followed by the semicolon character. For example, the entity definition:
______________________________________
<para>(C) &BSI;</para>
______________________________________
resolves to:
______________________________________
<para>(C) Bankers Systems, Inc.</para>.
______________________________________
It may be desirable, for example, to construct a paragraph of a document such that a list of remedial actions available to a creditor may be extended as needed. As is shown in the following exemplary declaration, a nested entity reference can be embedded to facilitate document extension:
______________________________________
<Para>The creditor can collect this debt from you
without first trying to collect from the borrower.
The creditor can use the same collection methods
against you that can be used against the Borrower,
such as suing you, &AdditionalMethods; etc. If this
debt is ever in default, that fact may become a part
of your credit record.</Para>.
______________________________________
In the above example, the default list of actions that can be used against the cosigner could be established by defining the entity AdditionalMethods as being empty. In this case, the implicated sentence above would read ". . . such as suing you, etc." If it is desirable to extend the list of remedial actions, the entity AdditionalMethods may be defined to include some appropriate language, such as:
______________________________________
<!ENTITY AdditionalMethods "garnishing your wages, ">.
______________________________________
Using the above entity definition, the text concerning the extended list of remedial actions would read "such as suing you, garnishing your wages, etc." It can be appreciated that entities should be contextually valid and balanced. A balanced entity will typically contain a start tag and a corresponding end tag. Entities can be used in many ways. For purposes of explanation, it may be convenient to classify entities according to three basic types: Content Entities, Data Entities, and Marked Section Control Entities. A Content Entity is one that represents document language. Typical uses of Content Entities include: language re-use, such that many documents can reference the same entity; alternate text control, such that a user's right to substitute language will be controlled at the Content Entity level; and compliance tracking of regulatory content, such as by tracking links to a government regulations database that will be stored as attributes of the content entity. It is noted that a unit of language that is linked to a specific regulation should be defined as a content entity. A Data Entity name represents a specific use of data. It is important to note that data entity names are not database field names. A Data Entity name may be subject to specific presentation limitations that may not apply to a field, (e.g., customer-name on a particular document may be limited to 25 characters even though other presentations of customer-name may allow more characters). A Marked Section Control Entity is an entity whose resolved value can only be "INCLUDE" or "IGNORE." It is occasionally convenient to mark some portion of a text for special treatment by an SGML parser or other language processor. Certain portions of legal boilerplate, for example, may need to be included or omitted systematically, depending on the state in which the document is intended to be valid. For example, the statement "Liability is limited to $50,000" may need to be included in Delaware, but excluded in Maryland. If a Marked Section Control Entity resolves to INCLUDE, the section it controls appears in the document, otherwise, the section does not appear in the document. Marked Section Control Entities are resolved before the document can be completely assembled. It is also possible that the resolution of Marked Section Control Entities will reveal other (nested) Marked Section Control Entities that must also be resolved. The ability to efficiently and accurately resolve entities of differing types and complexity in a predictable, controlled manner is an important feature of the present invention. Upon initial inspection, entities might appear to the skilled artisan to be nothing more than "include files," such as those used in program source files to re-use bits of source code. However, the entity resolution methodology of the present invention advantageously exploits the SGML parsing model so as to provide enhanced control of the entity resolution process. It will be appreciated that this enhanced entity resolution control capability is equally applicable to parsing schemes other than that defined by the SGML standard. It is understood that a particular entity may be defined multiple times and in multiple locations. The SGML Parser will resolve an entity reference by use of the first definition it finds. This characteristic of the SGML Parser model makes it possible to control the resolution of an entity by, for example, inserting a new definition upstream of a default definition. Referring now to FIGS. 9C and 10, entity references are resolved by the Entity Manager 152. The Entity Manager 152 is preferably a generalized entity resolver which can be utilized by other system clients that wish to resolve an entity name to a string, text, or other type of component. For example, the Entity Manager 152 may be used by the Inference Engine 28 or by a calculations service. When the SGML Parser 150 encounters an entity reference, such as the unresolved entity reference 24 indicated in FIG. 9C, the SGML Parser 150 transmits the entity name to Entity Manager 152. The Entity Manager 152 initially searches its Entity Cache 168 of resolved entity names and, if found, returns the corresponding string or file contents to the SGML Parser 150. In one embodiment, the Entity Manager 152 is implemented in a 32-bit DLL. In accordance with this embodiment, the service of the entity manager will be the only connection between the SGML Parser and the application. However, the services of the Entity Manager may also be used by any interested system client. If the entity name is not found in the Entity Cache 168, the Entity Manager 152 searches any of the Catalogs 26 that have been registered with it. In the context of an object-oriented programming implementation, an entity catalog is an object that maps an entity's external identifier or name to a file name or string value. The significant difference between the Entity Cache 168 and a Catalog 26 is that multiple catalogs can be loaded and catalogs may be read from a storage disk, while the Entity Cache 168 is constructed in memory and only one can exist. Any number of catalogs 26 may be defined and made available to the Entity Manager 152, including the following exemplary catalogs: a standard catalog that defines certain Marked Section Control Entities so as to manage the release of date-sensitive language; a catalog that defines entities such that static forms can be produced; an institution setup catalog that resolves data entities such as institution name and address; a branch setup catalog that resolves lender state, branch name, and address; a policy loan setup catalog for policy loans that may resolve any arbitrary set of entities as is appropriate for a particular policy; a customer catalog that provides for resolving of entities such as customer name and address common to many transactions between the institution and the customer; and a transaction catalog that contains the contents of the Entity Cache 168 after all documents have been assembled. It is considered important to provide the enduser the ability to control the order in which the Entity Manager 152 evaluates the catalogs 26. A bank, for example, may wish to assert the primacy of the institution catalog over a branch catalog, thus preventing modification of the institution's specified alternate text by the branch location. As is illustrated in the following example, the precedence or primacy of one catalog over another may be controlled by the end-user. The code provided below in Table 1 illustrates the parsing of a document with a minimum number of objects:
TABLE 1
______________________________________
Public Function PrepareDocument(pDoc As String, pDocOut As String,
pErrorFile As String) As Long
Dim mySgmlMgr As Object
Dim myParser As Object
Dim myCatalog As Object
`. . . Create the SGMLManager object
Set mySgmlMgr = CreateObject("BSI.SgmlManager")
`. . . Load your Storage Manager(s)
If Not mySgmlMgr.LoadStorageManager("asksm.dll") Then
MsgBox "Unable to load asksm.dll Storage Manager."
PrepareDocument = False
Set mySgmlMgr = Nothing
Exit Function
End If
`. . . Load your catalog(s)
Set myCatalog = mySgmlMgr.PushBack("bsi.cat")
`. . . Create a parser
Set myParser = mySgmlMgr.CreateParser(Nothing)
`. . . Parse the document
PrepareDocument = .sub.--
myParser.ParseDocument("E", pDoc, pDocOut, PErrorFile)
`. . . Destroy the objects
Set myCatalog = Nothing
Set myParser = Nothing
Set mySgmlMgr = Nothing
End Function
______________________________________
In order to utilize multiple catalogs, a separate object must be created for each catalog to be loaded. An efficient means to create multiple catalog objects is to create an array of objects, as illustrated in the code of Table 2 below:
TABLE 2
______________________________________
Dim myCatalogs( ) As Object
Dim myFilename As String
`. . . Read text file myFile for the
`. . . names of the catalogs to load
`. . . Read first record
Line Input #myFile, myFilename
Do While Len(myFilename)
`. . . Allocate a place for the catalog
ReDim Preserve myCatalogs(UBound(myCatalogs) + 1)
`. . . Put the catalog at the back
Set myCatalogs(UBound(myCatalogs)) .sub.--
= mySgmlMgr.PushBack(myFilename)
`. . . Read nextrecord
Line Input #myFile, myFilename
Loop
______________________________________
It is preferable for purposes of enhancing control of the entity reference resolution process that entities are always resolved in a consistent manner. The Entity Manager 152 initiates its evaluation at the front-most catalog, such as Catalog 1 shown in FIG. 9C, and continues progressively toward the back-most catalog, such as Catalog N. The Entity Manager 152 searches for the first occurrence of an entity identifier in the sequence of catalogs that matches the name of the entity reference to be resolved. Thus, the Entity Manager 152 will implement the first resolution strategy it locates upon determining the occurrence of a matching condition. This progression through multiple catalogs by the Entity Manager 152, however, can be advantageously altered in a controlled manner by inserting an appropriate matching entry in the front-most catalog. If it is uncertain which catalog instance is the front-most catalog, a CatalogPrecedence object can return a catalog object at an arbitrary position in the precedence. The following subroutine provided in Table 3 demonstrates this capability:
TABLE 3
______________________________________
Public Sub InsertEntitylnFrontmost( .sub.--
pPrecedence As Object, .sub.--
pEntityName As String, .sub.--
pStorageMgrName As String, .sub.--
pSystemID As String) as integer
Dim myFrontCatalog As Object
`. . . Get the front catalog
Set myFrontCatalog = pPrecedence.Index(0&)
myFrontCatalog.AddEntity pEntityName, .sub.--
pStorageMgrName, pSystemID
Set myFrontCatalog = Nothing
End Sub
______________________________________
This subroutine can be modified to enable controlled insertion of a catalog entry in any arbitrary position by including the position number as a parameter. As such, the client of this subroutine must be informed as to the number of loaded catalogs, which can be determined by the Count method of the Catalog Precedence. An Entity Browser, shown in FIGS. 11 and 12, is a tool that permits a user to navigate an Entity Dictionary 166. The Entity Browser provides search and sequence functions and is supported and managed by the DMS 174. It also enables a user to access and modify the attributes of an entity, as well as the text of Content Entities. For entities that have rules expressed in an Inference Engine 28, the Entity Browser connects to the editor of the Inference Engine 28. The Entity Browser is a user's interface to entities when authoring alternate or additional text. It is also used when the user is defining entities for user-supplied electronic forms. Custom Interfaces may be supplied for one or more Entity Dictionaries. Such custom interfaces typically contain the definitions of entities that are specific to certain data processors or user interfaces. Control of the entity resolution process is further enhanced by permitting users, such as financial institutions and their branches, to author alternate text that contains entity references in addition to those initially provided to the users. The institution, for example, may wish to specify that the institution's Entity Dictionary 166 be searched before the branch's Entity Dictionary 166, or vice versa. Each entity is referenced to one or more business rules that describe the transformations required to respond to an entity resolution request. FIG. 6 shows the main classes of transformations or business rule types. A non-transformation, indicated by line 106, is an action that simply moves a string from some source to the Entity Cache 168. A simple transformation, as indicated by line 108, is an action in which data is altered in some way between the source and the Entity Cache 168. For example, a data value of `1` may be transformed to "INCLUDE," while all other data values are transformed to "IGNORE." By way of further example, a floating point number may be formatted according to some particular specification. A complex transformation as indicated by line 110, is, by definition, any transformation that is not simple. A complex transforation may involve concatenating the values of several entities. It may involve some interaction with a Calculations Service, an Inference Engine 28, or any other business object. In view of the potential number and diversity of Entity Dictionaries, it is important to define a common data model for entities. It may be desirable, therefore, to ascribe an entity the attributes defined in Table 4 below:
TABLE 4
______________________________________
ATTRIBUTE ATTRIBUTE DEFINITION
______________________________________
ENTITY TYPE: GENERAL (ALL ENTITIES)
Entity Name The name used in the entity definition
Public Identifier
A name corresponding to the entity name
used in formal SGML document
interchange and written according to
the SGML standard
Owner BSI (Manufacturer) or USR (User)
Entity Type Data (DTA), Language (LNG), Marked
Section Control (MSC)
Resolution The default mechanism for resolving
Process.sub.-- Formal
this entity if it is not in the Entity
Cache or the catalogs. Values can be:
the Inference Engine (IE) 28 - the
entity name is the rule identifier; the
Entity Dictionary 166 (ED) - the value
in the Blank Form Value field is used
to resolve this entity
Resolution The probable part of the application
Process.sub.-- Short
that will supply the resolution.
Examples are "Institution Information",
"Borrower Information", "Transaction
Info - General"
Description A narrative describing the entity
Loan Purpose An entity could be identified as
specific to one or more loan purposes,
including consumer, commercial, or
agricultural.
Author The person who created the entity.
Date Created Date the entity was entered in the
Entity Dictionary 166
Date Last Modified
Date the entity was last changed.
Modified By Person made the last change to the
entity
Indexing Minimum and maximum index potentials
Constraints
Maximum Length
Maximum length of the string that
resolves this entity.
ENTITY TYPE: CONTENT AND MARKED SECTION CONTROL
ENTITIES
User override Can this entity be replaced by the
user?
SGML File Name
If applicable, the name of the file
containing the SGML text of the entity.
______________________________________
As mentioned previously, the Entity Browser tool shown in FIG. 12 provides a document developer or an enduser an interface to modify entity definitions and textual content. When invoked from an application, for example, the Entity Browser allows the user to specify or insert their own text for any entity flagged as customer modifiable. In addition, the user can insert or modify entity names using any name selected from a set of entity names provided by the application developer. Further, the user can exploit a User Defined Fields mechanism in order to define new entity names. User defined entity names are preferably prefixed with "U." designation. Collection of data values for User Defined Fields is handled by the User Defined Fields subsystem. An important feature concerns the transformation of an SGML document instance into a static form or document. A static form or document is understood to have a stable or pre-established structure after being constructed into which user information may be subsequently inserted. The structure of a static document, however, is generally not alterable by the end-user. In accordance with the present invention, a static document is constructed dynamically and subsequently published in a pre-printed or electronic static format. In contrast to a static form, a dynamic form has a structure that may be altered to accommodate transaction data, generally to meet a previously unperceived requirement, such as the selection of certain disclosures due to the transaction interest rate and repayment terms. A key distinction is that a static form is one that remains unchanged for many transactions, while a dynamic form is one that is unique for each transaction. The document construction methodology of the present invention provides for the dynamic construction and alteration of both static and dynamic documents and forms. In the construction of either a static or dynamic document, all entity references incorporated in the document must be resolved. It is noted that the resolution of Marked Section Control Entity references contained in a static form or document may differ from the resolution of the same Marked Section Control Entity references incorporated in a dynamic document. Most Data Entities will resolve to white or blank space in a static form. The process that transforms the SGML document will produce the PCL (Printer Control Language) files for each page and a text format file that describes the locations of the fields on the form, preferably by describing the Cartesian X and Y location coordinates of the fields on the form. The control parameters for the transformation process are captured along with the transaction catalog. When the appropriate entities are resolved such that the static SGML form is constructed, this set of entity resolutions is obtained from two catalogs. The entities necessary to generate the language of the constructed document are obtained from an E-form Control Catalog. The remaining entities, those that represent the white or blank space on the static form, are obtained from a separate E-form Data Catalog. An entity resolution in the E-form Data Catalog, for example, might be 25 blank spaces, or 40 underlines. The E-form Data Catalog is used to produce the pre-printed version of the static form. A control instance is a separate SGCML instance that is generated by the BFO Processor from a BFO file. The control instance conforms to a DTD authored specifically to support e-form merge files. Tools and documentation to support end-user creation of a control instance may be provided to permit development of custom forms by the user. Such a tool would support field creation and modification, as well as browsing of the entities available for user selection. The following code illustrates one embodiment of how a control instance might appear:
TABLE 5
______________________________________
<!DOCTYPE EFORM SYSTEM [
->-- Provide for subsetting the DTD
<!ENTITY % BSI.TRAN.DTDsubset
PUBLIC "-//BSI//ENTITIES Transaction declaration subset//EN">
%BSI.TRAN.DTDsubset;
]>
<EFORM>
<FM><FormFileName="myform.bfo"></FM
<Body>
<EformField FXYName="field1">&BSI.DC.CustName.25CharMax;
</EformField>
<EformField FXYName="field2">&BSI.DC.CustAddr1.25CharMax;
</EformField>
<EformField FXYName="field3">&BSI.DC.CustAddr2.25CharMax;
</EformField>
<EformField FXYName="field4">&BSI.DC.CustAddr3.25CharMax;
</EformField>
</Body>
</EFORM>
______________________________________
When the control instance is assembled, it will resolve each Data Entity with the same process as a dynamic document. In the above example of Table 5, the entities to be resolved are shown below in Table 6:
TABLE 6
______________________________________
BSI. TRAN.DTDsubset
the transaction catalog.
BSI.DC.CustName.25CharMax
a data entity (customer name
no longer than 25
characters.)
BSI.DC.CustAddr1.25CharMax
a data entity (customer
address 1 no longer than 25
characters.
BSI.DC.CustAddr2.25CharMax
a data entity (customer
address 2 no longer than 25
characters.
BSI.DC.CustAddr3.25CharMax
a data entity (customer
address 3 no longer than 25
characters.
______________________________________
The transformation process for a control instance provides for the creation of a merge file that can be supplied to a merge tool. For the instance resolved in Table 5 above, the transformation engine determines that the electronic form is located in the file "myform.bfo." When examining this form file, the transformation engine determines that it is a BSI electronic form, for example, and therefore produces a merge file according to that specification. If the electronic form were determined to be a JetForm (.MDF) file, by way of further example, the process would locate the appropriate field position coordinates file and produce the proper command stream for effecting the JetForm MiniMerge process. For purposes of illustrating the advantages of resolving an entity reference by cooperative operation between the Entity Manager 152 and an Inference Engine 28, the following example is provided. In order to resolve a particular entity reference, the Storage Manager 154 invokes the Inference Engine 28 in accordance with the resolution strategy associated with a matching catalog entity identifier. During the entity reference resolution process, the Inference Engine 28 investigates whether Regulation-Z applies. This inquiry by the Inference Engine 28 may be implemented in the following manner:
TABLE 7
______________________________________
SomeRule
select:
case : (RegZApplies)
{
// some action
}
default:
{
T;
}
}
RegZApplies
{
ASK ("&RegZApplies;" IsTorF(*), RegZApplies);
}
______________________________________
It is noted that two rules are used, which provides several advantages. First, the actual implementation of the RegZApplies logic is "hidden" from the referencing rule (SomeRule). Whether the referencing rule performs some logic or represents a simple entity reference is of no import to the referencing rule, or to the author of the rule. The Inference Engine 28 simply needs to know whether or not Regulation-Z applies. This insulation of the logic implementation from the referencing rule advantageously provides for the re-use of rules. A second advantage is that the Inference Engine 28 does not need to know any particulars about the Entity Manager 152. It is desireable that the Inference Engine 28 not be "customized" for any particular possible client in order to maximize its effectiveness. The Inference Engine 28 should be defined so as to be flexible enough to communicate with a wide variety of clients. The string passed back in the ASK transaction may be anything that the caller will understand and be able to resolve. With further reference to the example of Table 7 above, the Inference Engine 28 requests the Entity Manager 152 for a value for "&RegZApplies;". If RegZApplies has not yet been evaluated, the Entity Manager 152 preferably invokes the Inference Engine 28, or other Storage Manager registered to resolve RegZApplies. Once resolved, the Entity Manager 152 stores that value in the Entity Cache 168, thus making it available to the SGML Parser 150 and any other Entity Manager client. Consider the case is which state-specific language may be selected for a given document through the use of Marked Section Control Entities. Initially, each document is authored such that the language for all states is ignored. The application simply defines the Marked Section Control Entity for the desired state to "INCLUDE" so as to cause a particular state's language to be incorporated in the document. Another significant advantage of the present invention concerns the capability to dynamically build SGML structure within a document. As is defined in the Definitions Section hereinabove, Iterators are scripts that can build SGML structures from the information published by business objects via catalogs. They can infer structure from entity names in the catalog and, with a given set of rules, construct an appropriate SGML entity. An exemplary iterator, in accordance with one embodiment, is described below in Table 8:
TABLE 8
______________________________________
A SAMPLE ITERATOR
______________________________________
;; Name element
(define Name
(list "m.sub.-- Name" "Name" "DATA"))
;; Description element
(define Description
(list "m.sub.-- Desc" "Description" "DATA"))
;; Collateral element
(define Collateral
(list "Collateral" "Collateral" "GROUP"
(list Name Description)))
;; CollateralList element
(define CollateralList
(list "m.sub.-- CollateralList" "CollateralList" "CONTAINER"
(list Collateral)))
;;the following statement executes the iterator
(itr-item-container "TXN." CollateralList 1 "COUNT")
______________________________________
The following items are required prerequisites to defining and utilizing an iterator in accordance with this embodiment: The DTD for the target document; the Entity Dictionary 166 entry that represents the location in the target document; and the list of entity names to be published by the business object(s). Examples of the prerequisites are provided in Table 9 below:
TABLE 9
______________________________________
The DTD section of interest is:
<!ELEMENT CollateralList
(Collateral+)>
<!ELEMENT Collateral
(Name,Description)>
<!ELEMENT Name
(#PCDATA)>
<!ELEMENT Description
(#PCDATA)>
An entity reference has been put in the document where the
CollateralList element construct must be entered. This may
be defined as:
<Para>The collateral items for this loan are:</Para>
&BSI.DTA.CollateralList;
<Para>The above items . . .
An entry is created in the catalog that associates the
entity BSI.DTA.CollateralList with an iterator. The
specification of this entity may be defined as:
ENTITY BSI.DTA.CollateralList "<SCHEME>CollateralList"
A business object CollateralList in the transaction
publishes according to the following rules:
1. A member COUNT will be published containing the number
of collateral items.
2. For each item in the list, a string "ITEM.sub.-- #" will be
published in front of the name where `#` is the index
in the list.
3. A "TYPE" will be published for each ITEM.sub.-- # specifying
what kind of item it is.
In addition, CollateralList is a list of Collateral
business objects. Thus, for each object of this type, the
following will be published:
Name Description
______________________________________
m.sub.-- Name The name of the collateral item.
m.sub.-- Desc A description of the collateral item.
m.sub.-- Value
A dollar value attached to the
collateral item.
______________________________________
From the above information, it can be assumed that a catalog similar to the following provided in Table 10 may be published by the business object:
TABLE 10
__________________________________________________________________________
TXN.m.sub.-- CollateralList.COUNT
"<LITERAL asis>3"
TXN.m.sub.-- CollateralList.ITEM.sub.-- 1.TYPE
"<LITERAL asis>Collateral"
TXN.m.sub.-- CollateralList.XTEM.sub.-- 1.Collateral.m.sub.-- Name
"<LITERAL asis>10' boat"
TXN.m.sub.-- CollateralList.ITEM.sub.-- 1.Collateral.m.sub.-- Desc
"<LITEEAL asis>A standard boat"
TXN.m.sub.-- CollateralList.ITEM.sub.-- 1.Collateral.m.sub.-- Value
"<LITERAL asis>$500.00"
TXN.m.sub.-- CollateralList.ITEM.sub.-- 2.TYPE
"<LITERAL asis>Collateral"
TXN.m.sub.-- CollateralList.ITEM.sub.-- 2.Collateral.m.sub.-- Name
"<LITERAL asis>'79 Monza"
TXN.m.sub.-- CollateralList.ITEM.sub.-- 2.Collateral.m.sub.-- Desc
"<LITERAL asis>A bad car"
TXN.m.sub.-- CollateralList.ITEM.sub.-- 2.Collateral.m.sub.-- Value
"<LITERAL asis>$100.00"
TXN.m.sub.-- CollateralList.ITEM.sub.-- 3.TYPE
"<LITERAL asis>Collateral"
TXN.m.sub.-- CollateralList.ITEM.sub.-- 3.Collateral.m.sub.-- Name
"<LITERAL asis>Home"
TXN.m.sub.-- CollateralList.ITEM.sub.-- 3.Collateral.m.sub.-- Desc
"<LITERAL asis>Borrower's Home"
TXN.m.sub.-- CollateralList.ITEM.sub.-- 3.Collateral.m.sub.-- Value
"<LITERAL asis>$8900.00"
__________________________________________________________________________
When writing an iterator script, the following objectives should be considered. A CollateralList start and end tag must be wrapped around the whole construct. For each item, a Collateral start and end tag must be wrapped around the Collateral name and description. The m.sub.-- Name member's fully qualified entity must be wrapped with the Name tag inside the collateral element. The m.sub.-- Desc member's fully qualified entity must be wrapped with the Description tag inside the collateral element. The m.sub.-- Value is ignored for each element. In order to accomplish these objectives, the iterator code should be written to include a description of the mapping of m.sub.-- Name to Name. This is accomplished by declaring a mapping from the unqualified m.sub.-- Name entity to the Name element that is of a type "DATA." This signifies that the unqualified entity m.sub.-- Name will, when qualified, hold the data which must be inserted in the Name tag. This portion of the iterator code may be similar to following:
______________________________________
(define Name
(list "m.sub.-- Name" "Name" "DATA")).
______________________________________
The above code indicates that the unqualified m.sub.-- Name entity will be tagged with the element Name which is a data element. This will produce the following: <Name>&Something.m.sub.-- Name;</Name>; where `Something` is the qualification for m.sub.-- Name such that the appropriate entity is retrieved. A description of the mapping of m.sub.-- Desc to Description may be specified in the following manner:
______________________________________
(define Description
(list "m.sub.-- Desc" "Description" "DATA")).
______________________________________
The above code will produce the following:
______________________________________
< Description >&Something.m.sub.-- Desc;</ Description >.
______________________________________
A description of the mapping and structure of Collateral may be specified in the following manner:
______________________________________
(define Collateral
(list "Collateral" "Collateral" "GROUP"
(list name Description))).
______________________________________
In this description, the collateral element is being mapped from the entity name part `Collateral.` This is required because in the published catalog, every ITEM.sub.-- # was followed by the type "Collateral." Every member of "Collateral" will be prefaced by this name. Thus, to access "m.sub.-- Name," it is necessary to know that collateral is before it. In addition, the name "Collateral" was the name used in the "TYPE" entity for each item. This is important if a list object contains different kinds of information. A description of the mapping and structure of CollateralList may be specified in the following manner:
______________________________________
(define CollateralList
(list "m.sub.-- CollateralList" "CollateralList"
"CONTAINER"
(list Collateral))).
______________________________________
This description essentially indicates that the CollateralList element is mapped from the entity name part m.sub.-- CollateralList and is a container. A container may contain multiple different kinds of objects. In this case, it is stated that the CollateralList element may only contain Collateral elements, as was specified in the content model for CollateralList. The following iterator definition is provided in Table 11 below:
TABLE 11
______________________________________
;; Name element
(define Name
(list "m.sub.-- Name" "Name" "DATA"))
;; Description element
(define Description
(list "m.sub.-- Desc" "Description" "DATA"))
;; Collateral element
(define Collateral
(list "Collateral" "Collateral" "GROUP"
(list Name Description)))
;; CollateralList element
(define CollateralList
(list "m.sub.-- CollateralList" "CollateralList" "CONTAINER"
(list Collateral)))
;;the following statement executes the iterator
(itr-item-container "TXN." CollateralList 1 "COUNT")
______________________________________
The iterator defined in Table 11 above will produce the following using the catalog of Table 10 above:
TABLE 12
______________________________________
<CollateralList>
<Collateral>
<Name>&TXN.m.sub.-- CollateralList.ITEM.sub.-- 1.Collateral.m.sub.--
Name;</Name>
<Description>&TXN.m.sub.-- CollateralList.ITEM.sub.-- 1.Collateral.m.sub.-
- Desc;
</Description>
</Collateral>
<Collateral>
<Name>&TXN.m.sub.-- CollateralList.ITEM.sub.-- 2.Collateral.m.sub.--
Name;</Name>
<Description>&TXN.m.sub.-- CollateralList.ITEM.sub.-- 2.Collateral.m.sub.-
- Desc;
</Description>
</Collateral>
<Collateral>
<Name>&TXN.m.sub.-- CollateralList.ITEM.sub.-- 3.Collateral.m.sub.--
Name;
</Name>
<Description>&TXN.m.sub.-- CollateralList.ITEM.sub.-- 3.Collateral.m.sub.-
- Desc;
</Description>
</Collateral>
</CollateralList>
______________________________________
An iterator may be characterized as being one of three types: a data element description; a group element description; and a container element description. A data element is an element that has a model of #PCDATA, which is defined in the SGML Standard as "parsable character data." The content of the element is the value of some particular entity. The entity that should map to this element may have many different parents depending on where the entity was published. Thus, in the data element definition the entity is only specified by its terminating name. That is, the entity name to map from is the trailing name from the catalog whose parent may be many different things. During iteration, a procedure called itr-data is called to iterate a data element. This procedure is provided with the parent name. From the parent name and the terminating name, a full entity name may be specified. The syntax of a data element definition is provided as follows:
TABLE 13
______________________________________
data-element-def
=> (define name data-element-desc)
data-element-desc
=> (list entity-name element-name
"DATA")
entity-name
=> literal
element-name
=> literal
name => a name following scheme naming conventions
literal => a quoted string following scheme conventions
An example of data element:
;; Name element
(define Name
(list "m.sub.-- Name" "Name" "DATA"))
______________________________________
A group element is an element whose content model is made up of a collection of sub-elements. The definition defines the order in which the sub-elements can appear and what iterator definition to use to create such sub-elements. In addition, it can specify whether there is an entity name fragment that should be appended to the parent so that the sub-elements have the appropriate parent name to build their entity references. The syntax of the group element definition is as follows:
TABLE 14
______________________________________
group-element-def
=> (define name group-element-desc)
group-element-desc
=> (list entity-name element-name
"GROUP" group-content-desc)
entity-name
=> literal .linevert split. null
element-name
=> literal
name => a name following scheme naming conventions
literal => a quoted string following scheme conventions
null => `( )
group-content-desc
=> (list definition-by-name+ )
definition-by-name
=> name
Note: A definition-by-name must be previously defined as some kind of
valid iterator definition.
An example:
;; Name element
(define Name
(list "m.sub.-- Name" "Name" "DATA"))
;; Description element
(define Description
(list "m.sub.-- Desc" "Description" "DATA"))
;; Collateral element
(define Collateral
(list "Collateral" "Collateral" "GROUP"
(list Name Description)))
______________________________________
A container element is an element that can contain more than one of a set of elements, including itself. That is, a container element can contain other container elements and itself. The definition contains a set (list) of elements that can be contained within the element. The syntax of the container element definition is as follows:
TABLE 15
______________________________________
container-element-def
=> (define name container-element-desc)
container-element-desc
=> (list entity-name element-name
"CONTAINER" container-content-desc)
entity-name => literal .linevert split. null
element-name => literal
name => a name following scheme naming
conventions
literal => a quoted string following scheme
conventions
container-content-desc
=> (list ( definition-by-name .linevert split.
self-ref )+ )
definition-by-name
=> name
self-ref => (list entity-name element-name "SELF")
element-name "SELF")
An example is:
;; Borrower element
(define Borrower
(list "m.sub.-- Party" "Borrower" "GROUP"
(list Name Address)))
;; BorrowerGroup element
(define BorrowerGroup
(list "m.sub.-- BorrowerList" "BorrowerGroup" "CONTAINER"
(list Borrower
(list "m.sub.-- BorrowerList" "BorrowerGroup"
"SELF"))))
______________________________________
Three different commands may be used to manipulate iterator scripts. The first command is "itr-data." This command iterates a data element definition and a given catalog, and generates a data element SGML component. An exemplary usage of this command is given by (itr-data parent definition). The second command is "itr-group." This command iterates a data element definition and a given catalog, and generates a group element SGML component. An exemplary usage of this command is given by (itr-group parent definition). The third command is "itr-item-container." This command iterates a container element definition and a given catalog from a start index to an end index, and generates a group element SGML component. The start and end index values can be given as a terminal entity name to be retrieved from the catalog. An exemplary usage of this command is given by:
TABLE 16
______________________________________
(itr-item-container parent definition string string)
;; or
(itr-item-container parent definition number string)
;; or
(itr-item-container parent definition string number)
;; or
(itr-item-container parent definition number number).
______________________________________
In order to illustrate an advantageous use of an iterator when constructing a document, the following example is provided. In this example, a borrower construct needs to be generated using an iterator conforming to the following rules: first, a BorrowerGroup start and end tag must be wrapped around the whole construct; second, a Borrower Group consists of one or more Borrower or BorrowerGroup elements; third, if the item is a borrower, a Borrower element will be tagged; fourth, if the item is a borrower list, a Borrower Group element will be tagged; fifth, the following DTD component of Table 17 will be used:
TABLE 17
______________________________________
<!ELEMENT BorrowerGroup
((Borrower.linevert split.BorrowerGroup)
.sup. +) >
<!ELEMENT Borrower
(ComplexName,
.sup. PermAddress) >
<!ELEMENT ComplexName
(FirstName,LastName) >
<!ELEMENT (FirstName.linevert split.LastName)
(#PCDATA)
<!ELEMENT PermAddress
(Street+,City,State,Country) >
<!ELEMENT (Street.linevert split.City)
State.linevert split.Country)
(#PCDATA) >
______________________________________
Finally, a catalog will be published similar to the following partial catalog of Table 18 below:
TABLE 18
__________________________________________________________________________
ENTITY TXN.m.sub.-- BorrowerList.COUNT "<LITERAL asis>3"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.TYPE "<LITERAL
asis>Party"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- FirstName
"<LITERAL asis>"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- LastName
"<LITERAL asis>"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- MailCity
"<LITERAL asis>"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- MailCountry
"<LITERAL asis>USA"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- MailCounty
"<LITERAL asis>"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- MailFromDate
"<LITERAL asis>"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- MailNonUS
"<LITERAL asis>0"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- MailState
"<LITERAL asis>"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- MailStreet
"<LITERAL asis>"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- MailToDate
"<LITERAL asis>"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- MiddleName
"<LITERAL asis>"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- PermCity
"<LITERAL asis>"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- PermCountry
"<LITERAL asis>USA"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- PermCounty
"<LITERAL asis>"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- PermFromDate
"<LITERAL asis>"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- PermNonUS
"<LITERAL asis>0"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- PermOwnRent
<LITERAL asis>1"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- PermPostatlC
ode "<LITERAL asis>"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- PermState
"<LITERAL asis>"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- PermStreet1
"<LITERAL asis>"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- PermToDate
"<LITERAL asis>"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 2.TYPE "<LITERAL
asis>Party"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 2.Party.m.sub.-- FirstName
"<LITEEAL asis>"
ENTITY TXN.m.sub.-- BorrowerList.ITEM.sub.-- 2.Party.m.sub.-- LastName
"<LITERAL asis>"
__________________________________________________________________________
In order to accomplish these objectives, the following iterator code is provided in Table 19 below:
TABLE 19
______________________________________
An iterator definition for Borrower is given by:
;; ComplexName element:
(define FirstName
(list "m.sub.-- FirstName" "FirstName" "DATA"))
(define LastName
(list "m.sub.-- LastName" "LastName" "DATA"))
(define ComplexName
(list '( ) "ComplexName" "GROUP" (list FirstName
LastName)))
;; PermAddress element:
(define Street
(list "m.sub.-- PermStreet" "Street" "DATA"))
(define City
(list "m.sub.-- PermCity" "City" "DATA"))
(define State
(list "m.sub.-- PermState" "State" "DATA"))
(define Country
(list "m.sub.-- PermCountry" "Country" "DATA"))
(define PermAddress
(list '( ) "PermAddress" "GROUP" (list Street City
State Country)))
; Borrower Element
(define Borrower
(list "Party" "Borrower" "GROUP" (list ComplexName
PermAddress)))
An iterator definition for BorrowerGroup is given by:
;; BorrowerGroup Element
(define BorrowerGroup
(list "m.sub.-- BorrowerList" "BorrowerGroup" "CONTAINER"
(list
Borrower
(list "m.sub.-- BorrowerList" "BorrowerGroup"
"SELF"))))
The iterator must be invoked by the following:
;; Iterate all borrowers
(itr-item-container "TXN." BorrowerGroup 1 "COUNT")
______________________________________
The above defined iterator of Table 19 will produce the following using the catalog of Table 18 above:
TABLE 20
__________________________________________________________________________
<BorrowerGroup>
<Borrower>
<ComplexName>
<FirstName>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.--
FirstName;</FirstName>
<LastName>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.--
LastName;</LastName>
</ComplexName>
<PermAddress>
<Street>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- PermStreet
1;</Street>
<City>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- PermCity;</C
ity>
<State>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1 .Party.m.sub.-- PermState;
</State>
<Country>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 1.Party.m.sub.-- PermCount
ry;</Country>
</PermAddress>
</Borrower>
<Borrower>
<ComplexName>
<FirstName>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 2.Party.m.sub.--
FirstName;</FirstName>
<LastName>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 2.Party.m.sub.--
LastName;</LastName>
</ComplexName>
<PermAddress>
<Street>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 2.Party.m.sub.-- PermStreet
1;</Street>
<City>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 2.Party.m.sub.-- PermCity;</C
ity>
<State>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 2.Party.m.sub.-- PermState;<
/State>
<Country>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 2.Party.m.sub.-- PermCount
ry;</Country>
</PermAddress>
</Borrower>
<BorrowerGroup>
<Borrower>
<ComplexName>
<FirstName>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 3.m.sub.-- BorrowerList.
ITEM.sub.-- 1.Party.m.sub.-- FirstName;</FirstName>
<LastName>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 3.m.sub.-- BorrowerList.I
TEM.sub.-- 1.Party.m.sub.-- LastName;</LastName>
</ComplexName>
<PermAddress>
<Street>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 3.m.sub.-- BorrowerList.ITE
M 1.Party.m.sub.-- PermStreet1;</Street>
<City>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 3.m.sub.-- BorrowerList.ITEM.
sub.-- 1.Party.m.sub.-- PermCity;</City>
<State>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 3.m.sub.-- BorrowerList.ITEM
.sub.-- 1.Party.m.sub.-- PermState;</State>
<Country)&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 3.m.sub.-- BorrowerList.IT
EM.sub.-- 1.Party.m.sub.-- PermCountry;</Country>
</PermAddress>
</Borrower)
<Borrower>
<ComplexName)
<FirstName>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 3.m.sub.-- BorrowerList.
ITEM.sub.-- 2.Party.m.sub.-- FirstName;</FirstName>
<LastName>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 3.m.sub.-- BorrowerList.I
TEM.sub.-- 2.Party.m.sub.-- LastName;</LastName>
</ComplexName>
<PermAddress>
<Street>&TXN.m.sub.-- BorrowerList.ITEM 3.m.sub.-- BorrowerList.ITEM.sub.-
- 2.Party.m.sub.-- PermStreet1;</Street>
<City>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 3.m.sub.-- BorrowerList.ITEM.
sub.-- 2.Party.m.sub.-- PermCity;</City>
<State>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 3.m.sub.-- BorrowerList.ITEM
.sub.-- 2.Party.m.sub.-- PermState;</State>
<Country>&TXN.m.sub.-- BorrowerList.ITEM.sub.-- 3.m.sub.-- BorrowerList.IT
EM.sub.-- 2.Party.m.sub.-- PermCountry;</Country>
</PermAddress>
</Borrower>
</BorrowerGroup></BorrowerGroup>
__________________________________________________________________________
It is noted that the above listing was generated from a catalog that continued from the partial catalog shown in Table 18 above. Since the entire catalog is very large, only a portion was provided in Table 18 to illustrate the advantageous use of iterators in accordance with one embodiment of the present invention. The concept of an iterator will now be expressed in terms of its specific use as a Storage Manager 154 within the context of the embodiments illustrated in FIGS. 9C and 10. In the following illustrative example, the more important steps involved in constructing a document in accordance with these embodiments are described. These document construction steps include: STEP 1--collecting transaction data (instantiating business objects); STEP 2--publishing data (each business object writes itself to a catalog); STEP 3--autoselection (transform the Comprehensive Document List to the Suggested Document List); STEP 4--interacting with the user to create the Selected Document List from the Suggested Document List; STEP 5--determining whether additional data must be collected and, if so, notifying the user; STEP 6--generating documents (resolving document entities); and STEP 7--formatting, previewing, and printing a resolved document. In this illustrative example, it is assumed that an Iterator Storage Manager declaration is defined and is included in a Catalog 26 in accordance with the following syntax:
TABLE 21
______________________________________
ENTITY entity-name
"ITR:itr-file-name//parm-name-1 (start-value[
end-value])// . . . //parm-name-n(start-value[
end-value])"
itr-file-name
The content to be iterated. The content must be in
a file. The file name can be entered directly
or referenced as an entity. If an entity name is
used, the content can be replaced/overridden by
normal catalog precedence.
parm-name-?
The name of the parameter. This is a name that
appears between pound marks (#) in itr-file-name.
For each parm-name, a stack is created, such that
a value can be set and manipulated.
start-value
The first value to be substituted for the
associated parm-name. An entity name can be
used. If end-value is omitted, a string or an entity
that returns a string can be used. Otherwise,
start-value must be an integer or an entity name
that resolves to an integer.
end-value
The last value to be substituted for the
associated parm-name. If end-value is omitted or
if end-value is the same as start-value,
itr-file-name is iterated once using start-value.
If end-value is supplied, itr-file-name is
iterated for each integer value between
start-value and end-value incrementing by +1
each time. If end-value is supplied, and if end-
value is less than start-value, itr-file-name is not
iterated. An entity name that returns an integer
can be used.
______________________________________
It is noted that the start and end values for parms can be qualified by parm-name delimited by pound marks in the same way that parameter names are qualified in itr-file-name. It is further noted that there is no mark between the start and end value. This allows the values be returned by a rule as a list. The content to be iterated, itr-file-name, must contain SGML processing instructions for each parm-name in order to control the scope of iteration. In Table 22 below, there is provided sample catalog entries that use the itr-file-name language provided in Table 23.
TABLE 22
______________________________________
ENTITY PartyInfo "ITR:&pPartyInfo;//PartyItem(1
&NumberParties;)//AddressNumber(1
&Party.sub.-- #PartyItem#.NumberofAddresses;)"
ENTITY pPartyInfo "FILE:Borrow.itr".
______________________________________
The following processing instructions can be included in itr-file-name:
TABLE 24
______________________________________
SCOPE parm-name
Marks the beginning of the language to
be varied over the range of values for
parm-name. When SCOPE is encountered,
the start-value and end-value values
for parm-name are resolved, based on the
system ID. This allows the iteration to be
iteration to be customized for each specific
scope.
ENDSCOPE parm-name
Marks the end of the language to be
varied over the range of values for
parm-name.
IF parmstring EQ "value"
Marks the beginning of language to be
incorporated if the condition is true.
IFs can be nested.
ENDIF marks the end of language conditioned
by IF.
PUSH parm-name parm-string
Save the current value of parm-name in a
last-in, first-out stack, and replace
it with parm-string.
POP parm-name Restore the saved value of parm-name.
#parm-name# Pound marks are used to delimit
parm-name. Each time parm-name appears
between the pound mark delimiters, it will
be replaced by the current value of
parm-name.
parm-string Any sequence of printable ASCII
characters. If the sequence contains a
subsequence delimited by pound marks
(#), the subsequence will be processed
as a parm-name.
______________________________________
In a lending transaction, for example, there can be any number of co-parties to the transaction. Some of the co-parties may be co-signers, some may be guarantors, and the like. It may be desirable to list all parties in the documents, others may list only a specific party. In accordance with this example, the following assumptions are made. There exists a Parties business object which defines some data objects and a collection of items. The data objects of the Parties business object are m.sub.-- Count, m.sub.-- Name, m.sub.-- SubName. Its item collection contains one or more Party or Parties objects and can return the type of each object. The Party data object has data objects m.sub.-- Name, m.sub.-- SubName, m.sub.-- Phone, a collection of Address objects called m.sub.-- Address, and a collection of Signer data objects called m.sub.-- Signers. The Signer object has data objects m.sub.-- Name, and m.sub.-- Title. Each collection and data object is instantiated with a PubInfo property that the object uses when it publishes itself. Each collection has an m.sub.-- count property that returns the number of objects it contains. It is further assumed that the Parties business object is instantiated with the following values:
TABLE 25
__________________________________________________________________________
VARIABLE NAME VALUE PUBINFO
__________________________________________________________________________
Parties.m.sub.-- Name Parties.Name
Parties.m.sub.-- SubName Parties.SubName
Parties.m.sub.-- Count
2 Parties.Count
Parties.Item(1).Type
PARTY Parties.Item.sub.-- 1.Type
Parties.Item(1).m.sub.-- Name
John Jones
Parties.Item.sub.-- 1.Name
Parties.Item(1).m.sub.-- SubName
Parties.Item.sub.-- 1.SubName
Parties.Item(1).m.sub.-- Address.Count
3 Parties.Item.sub.-- 1.Address.Count
Parties.Item(1).m.sub.-- Address(1)
123 Easy Street
Parties.Item.sub.-- 1.Address.sub.-- 1
Parties.Item(1).m.sub.-- Address(2)
PO Box 456
Parties.Item.sub.-- 1.Address.sub.-- 2
Parties.Item(1).m.sub.-- Address(3)
Anywhere, USA
Parties.Item.sub.-- 1.Address.sub.-- 3
Parties.Item(1).m.sub.-- Phone
555-1234 Parties.Item 1.Phone
Parties.Item(2).Type
PARTY Parties.Item 2.Type
Parties.Item(2).m.sub.-- Name
Tim Allen
Parties.Item 2.Name
Parties.Item(2).m.sub.-- SubName
Parties.Item 2.SubName
Parties.Item(2).m.sub.-- Address.Coun
1 Parties.Item.sub.-- 2.Address.Count
Parties.Item(2).m.sub.-- Address(1)
Washington, DC
Parties.Item.sub.-- 2.Address
Parties.Item(2).m.sub.-- Phone
555-5432 Parties.Item.sub.-- 2.Phone
__________________________________________________________________________
Further, it is assumed that there is a document, Document A, that needs to contain party information for each party. There is another document, Document B, that needs to contain party information about Party 2. The DTD fragment of the document is give by:
TABLE 26
______________________________________
<!ELEMENT PartyInfo - O (Name , Address*, Phone?)>
<!ELEMENT Name - O (#PCDATA) --<Title>Name-- >
<!ELEMENT Address - O (#PCDATA) --<Title>Address-- >
<!ELEMENT Phone - O (#PCDATA)>
<!ATTLIST (Name .linevert split. Phone) Prefix CDATA #IMPLIED>
______________________________________
Document A is given by &PartiesInfo, Document B is given by MyPartyInfo, and the applicable catalog portion is give by the following:
TABLE 27
______________________________________
ENTITY PartiesInfo "ITR:&pPartyInfo;//PartyItem(1
&Parties.Count;)//AddressNumber(1
&Parties.Party.sub.-- #PartyItem#.NumberofAddresses;)"
ENTITY pPartyInfo "FILE:Borrow.itr"
ENTITY MyPartyInfo
"ITR:&pPartyInfo;//PartyItem(&MyPartyNumber;)//AddressNumber
(1 &Parties.Party.sub.-- #PartyItem#.Address.Count;)
______________________________________
It is further assumed that the file BORROWER.ITR is given by:
TABLE 28
______________________________________
<!-- File name: BORROW.ITR -->
<?SCOPE PartyItem>
<PartyInfo>
<Name prefix="Name of
Debtor">&Parties.Item.sub.-- #PartyItem#.Name;</Name>
<?SCOPE AddressNumber>
<Address>&Parties.Item.sub.-- #PartyItem#.Address.sub.-- #AddressNumber#;
</Address>
<?ENDSCOPE AddressNumber>
<Phone>&Parties.Item.sub.-- #PartyItem#.Phone;</Phone>
</PartyInfo>
<?ENDSCOPE PartyItem>
______________________________________
When it publishes itself, the Parties business object creates the following catalog:
TABLE 29
______________________________________
File name: Parties.cat
Date created: 9/14/95
ENTITY Parties.Name "LIT:"
ENTITY Parties.SubName "LIT:"
ENTITY Parties.Count "INT:2"
ENTITY Parties.Item.sub.-- 1.Type "LIT:PARTY"
ENTITY Parties.Item.sub.-- 1.Name "LIT:John Jones"
ENTITY Parties.Item.sub.-- 1.SubName "LIT:"
ENTITY Parties.Item.sub.-- 1.Address.Count "INT:3"
ENTITY Parties.Item.sub.-- 1.Address.sub.-- 1 "LIT:123 Easy Street"
ENTITY Parties.Item.sub.-- 1.Address.sub.-- 2 "LIT:PO Box 456"
ENTITY Parties.Item.sub.-- 1.Address.sub.-- 3 "LIT:Anywhere, USA"
ENTITY Parties.Item.sub.-- 1.Phone "LIT:555-1234"
ENTITY Parties.Item.sub.-- 2.Type "LIT:PARTY"
ENTITY Parties.Item.sub.-- 2.Name "LIT:Tim Allen"
ENTITY Parties.Item.sub.-- 2.SubName "LIT:"
ENTITY Parties.Item.sub.-- 2.Address.Count "INT:1"
ENTITY Parties.Item.sub.-- 2.Address.sub.-- 1 "LIT:Washington, DC"
ENTITY Parties.Item.sub.-- 2.Phone "LIT:555-5432"
______________________________________
At STEP 3 described hereinabove, the autoselection process, which is described in Appendix IV hereinbelow, determines that Document A is required and that Document B is required for party 2. The autoselection process causes the following document catalog for the Notice to Cosigner to be created:
TABLE 30
______________________________________
File name: DocumentB.cat
Date created: 9/14/95
ENTITY MyPartyNumber "INT:2"
______________________________________
At STEP 4, it is assumed that the user makes no changes in the Suggested Document List, so the Selected Document List is identical to the Suggested Document List and there is no additional data to collect. At STEP 6 (generate documents), Document A is resolved first. The following actions take place:
TABLE 31
______________________________________
&PartiesInfo; is resolved via the BSI catalog to
systemID"ITR:&pPartyInfo;//PartyItem(1&Parties.NumberOfParties;)
//AddressNumber(1&Party.sub.-- #PartyItem#.NumberOfAddresses;)"
The ITR Storage Manager creates stacks for PartyItem and
AddressNumber. The initial values pushed on the stacks are
PartyItem(1) and AddressNumber(1). When the SCOPE PartyItem
instruction is read, ITR duplicates PartyItem and pushes it
on the stack. For the first part of the scope, it emits:
<PartyInfo>
<Name prefix="Name of
Debtor">&Parties.Item.sub.-- 1.Name;</Name>
When the SCOPE AddressNumber processing instruction is read, the
ITR Storage Manager resolves the end-value for AddressNumber to 3 by
resolving Paries.Item.sub.-- 1.Address.Count. It duplicates the current
value of AddressNumber and pushes it on the stack.
Processing the scope for AddressNumber it emits:
<Address>&Parties.Item.sub.-- 1.Address.sub.-- 1;</Address>
The ENDSCOPE AddressNumber processing instruction increments
AddressNumber by 1 and compares to the end value. Since it is not
greater, control cycles to the SCOPE AddressNumber statement.
The ITR Storage Manager emits:
<Address>&Parties.Item.sub.-- 1.Address.sub.-- 2;</Address>
Again, the ENDSCOPE AddressNumber increments AddressNumber
and cycles:
<Address>&Parties.Item.sub.-- 1.Address.sub.-- 3;</Address>
Now | ||||||