AU2012203523A1 - Document automation systems - Google Patents

Abstract

DOCUMENT AUTOMATION SYSTEMS The present invention relates to document automationlassembly systems, and more particularly to document automation systems distributed over a network such as the Internet, and/or other communication networks. In addition, the present invention relates to methods, especially computer-implemented methods, to computer programs, 10 and to recording media storing such programs for use in such systems. a A UT HOR USER T ERMINAL T ERMINAL Fig. I AUT HR INT ERFACE AUTOR SCRIPT EDITING SYSTEM 1 AUTHORM INTERFACE REPOSITrORY Fig.2

Description

pool Section 29 Regul1Jon 3,2C2) AUSTRALIA Patents Act 1990 ORIGINAL COMPLETE SPECIFICATION STANDARD PATENT Application Number: Lodged: Invention Title: Document automation systems The following statement is a full description of this invention, including the best method of performing it known to us: P111AHAU/0710 IP Austraia 15 JUN 2012 RECEIVED FEP 1 DOCUMENT AUTOMATION SYSTEMS FIELD OF THE INVENTION 5 (0001] The present invention relates to document automation/assembly systems, and more particularly to document automation systems distributed over a network such as the Internet, and/or other communication networks. In addition, the present invention relates to methods, especially computer-Implemented methods, to computer programs, and to recording media storing such programs for use in such systems. 10 [0002J It wiil be appreciated that, although the embodiments and examples described herein are applied to a network, the present invention may be equally embodied on a single computer terminal or other processing device. 15 BACKGROUND OF THE INVENTION [0003] Many organisations are involved in the generation of documents. A law firm is an example of one such organisation. One of the main activities of a law firm is the drafting of legal documents such as agreements and contracts on behalf of its clients. 20 Such a client may be engaged in a transaction of some kind, which may be very complex. A lawyer or team of lawyers at the firm can be tasked with the drafting of documents to support that transaction. Such documents are notoriously lengthy and complex, and moreover a high degree of importance is typically attached to the accuracy of the content of such documents. It is accordingly desirable to generate 25 such documents in an efficient and accurate manner. [0004) A number of document automation systems exist. Such systems typically elicit data from a system user for use in the generation of a document. Using the above example, data about a particular transaction may be elicited from lawyers engaged in 30 the transaction project, and may be employed by such existing document automation systems to generate drafts of the requisite documents. Existing document automation systems typically allow users to modify the input data or to add new data, thereby modifying the generated documents. 35 2 [0005] Existing document automation systems use rules to generate documents based on the input data. In general, data may intmnt with Such rulot to form tho rnntnt nf a OefnQrted documont. Thorm are several wayo in vlilI a pleute ut dad May affect the content of a generated document. For example, a piece of data may itself be 5 expressed in the generated document. Alternatively, a section of the generated document may be inserted therein on condition that a piece of data has a certain value. [0006] For illustrative purposes, consider the following two simple examples of transaction data; (a) the name of the party who is acting as the buyer; and (b) the 10 information as to whether that party is a natural person or a legal person (e.g. a company). [0007] With regard to example (a), there may be several places in a generated document where the name of the buyer will be expressed. For example (supposing that 15 'Trustthorpe Ltd' is the name of the buyer), the generated document may contain the clause "17.2 Trustthorpe Ltd shall pay all present and future stamp, documentary and other like duties and taxes (if any) to which this agreement may be subject or may give rise...". That is, the rules responsible for generating the document may ensure that whatever value the piece of data holding the buyer's name possesses, that value will 20 appear in the locations that the rules specify, [0008] With regard to example (b), whether a party is a real person or a company can affect which clauses are included in a generated document. For instance, the generated document may be an agreement that has an execution clause at which the 25 party concerned should sign the agreement. The form of such an execution clause will normally be different in the case where the party is a company (legal person) from the case where the party Is a real person (natural person). In order to provide the right kind of clause in the appropriate circumstances, the rules responsible for generating the document may have an "if ... then ." form, such that the rules will effectively provide 30 that "if" the buyer is a company, "then" a particular clause should be used, however "if" the buyer is a real person, "then" a different clause should be used. [0009] There are other ways in which existing document automation systems use data in combination with rules to control the content of generated documents. The most 35 important and common of these is where a data structure is a collection of similar 3 pieces of data and, when the rules are written, it is not known how many items the collection contains. [0010] In such cases, the rules followed by the document generation system may 5 instruct the generation process to insert something once for each member of the collection, however many members that may be. The process of doing something once for each member of a collection is known as iteration. [0011] For example, suppose that the collection is of the names of the different 10 parties to an agreement; the rules may instruct the generation process to express each member of the collection, thus creating a list of parties. [0012] In more complex cases, what's Iterated might involve 'if.. .then..' rules. The 'if...then...' example above concerns the creation of different forms of execution clause, 15 and clearly one use of a more complex iteration would be to create, for each party to an agreement, an appropriate style of execution clause for that party. Here the iteration rule would specify that the 'if..then...' execution clause rule is to be executed for each party. 20 [0013] US 2006/0036612 discloses a document automation system that includes an assembler for generating an instance document on the basis of a source document and one or more logic-source documents referenced by the source document. The source document and logic-source documents are XML documents including at least one XML processing instruction. The source document and logic-source documents are valid 25 with respect to XML schema. The system generates an instance document in HTML, PDF or RTF format by resolving variables in the source document and/or logic sources using one or more data sources. [0014] GB 2405729 discloses a document generation system that generates a 30 customised document using content elements selected by rules operating on input information including transaction values. The system associates further rules with the transaction values and evaluates the further rules to produce an indication of the relevance of the presence or absence of the transaction values in a fully or partially customised generated document. The effect of the transaction values is represented by 35 means of a mark-up.

4 SUMMARY OF THE INVENTION [00151 The present invention relates to systems, methods and computer programs for 5 use in generating electronic documents, The present invention also relates to code carried by a signal or held on a carrier medium which when executed on a computing device provides a display element and/or a web page for a user of the system. [0016] According to an embodiment of an aspect of the present invention, there is 10 provided an electronic-document generation system comprising: generation means operable to employ a content source comprising document content and a logic source comprising logic to generate a target document by evaluating said logic in dependence upon data; a user interface operable to cause the target document or another electronic document generated therefrom to be displayed to a user, said user interface 15 being further operable to permit the user to make an amendment to the displayed document; and source-amending means operable, when such an amendment other than a change to said data is made to the displayed document, to effect an equivalent amendment to a corresponding portion of the content source and/or the logic source. 20 [0017] It is advantageous for a user of such a system to be able to amend a displayed document, other than by amending the data based upon which the document was generated, such that it will be regenerated in the amended form by the system in the future. Preferably, considering such a displayed document as amended by the user to be a current displayed document, the equivalent amendment is such that a 25 future such displayed document produced from the amended content and/or logic source would be substantially identical to said current displayed document. [0018] The logic used to generate the document could be a rule or set of rules, or a condition, or any other material that may express such a condition. The target 30 document may be expressed (written/defined) in a markup language, for example in XML. The displayed document may be a structured document, for example a legal document. [0019] The displayed document may be a formatted textual document. The logic 35 and/or content sources may be expressed (written/defined) in a markup language, for example in XML. The logic and/or content sources may be included in a script, for 5 example an XML script. The data may be simple data, or data having a complex structure or hierarchy. For example, the data may comprise one or more composite data items, each being an instance of a respective composite data typo. Such composite data items and data types are described in greater detail below, however an 5 understanding of such composite data items can be found at http:/Ien.wikipedia.oro/wiki/Composite datatype. [0020] Such a system is preferably arranged such that the content source and/or the logic source comprise at least one portion identified by a portion identifier, the or each 10 said portion being responsible for the generation of a corresponding portion of said target document; the generation means is operable, for the or each said portion of the target document, to include the corresponding portion identifier or a portion identifier derived therefrom in said target document: the user interface is operable to: permit the user to make an amendment other than a change to said data to a portion of the 15 displayed document corresponding to the or one of the portions of the target document: and communicate to said source-amending means the portion identifier included in the target document that corresponds to the amended portion of the displayed document, or a portion identifier derived therefrom, and information about the amendment made; and the source-amending means is operable to employ the communicated portion 20 identifier and the communicated information to effect an equivalent amendment to the portion of the content source and/or the logic source corresponding to the communicated portion identifier. [0021] The or each portion identifier is preferably unique amongst any other such 25 identifiers within said sources. In the case that the sources are expressed in a markup language, for example in XML, the or each portion identifier may be an element identifier identifying an element of the source concerned. [0022] Such a system is preferably arranged such that: the sources are associated 30 with a source identifier distinguishing them from other such sources employable by the generation means; the generation means is operable to include the source identifier, or an identifier derived therefrom, in said target document; the user interface is operable, following such an amendment, to communicate to said source-amending unit the source identifier included in the target document; and the source-amending unit is 35 operable to employ the communicated source identifier to effect an equivalent 6 amendment to the content source and/or the logic source corresponding to the o0mmuiclatedj uume~ W)idlller. [0023] Prmfnrably, the logic source and tho oontont source are included Witin 13 5 drafting script, which may be written in a markup language such as XML. Such a system may apply rules related to document structure, in order to identify the required corresponding amendments in such a source drafting script. Certain modifications may require no more then the insertion or deletion of text at a particular point in such a drafting script. Other changes might require structural modification as well, dependent 10 on the position and disposition of the triggering modification made by the user in the displayed "draft" document. [0024] For example, consider a modification by a user in a draft document which involves the insertion of text into a new paragraph immediately following an existing 15 paragraph. An equivalent corresponding change in a source drafting script instance may require the insertion of the new text in addition to the application of paragraphing tags to the new text, in order to achieve an amendment that is substantially identical (or equivalent) to the user's amendment in the draft document. 20 [0025] Rules relating to how to handle user amendments and make equivalent corresponding amendments in source drafting scripts may be based on a specified XML structure (in the case that the drafting scripts are defined in XML) known by the system and used to produce target documents, such that they conform to a DTD (Document Type Definition) defined for target documents. This aspect of the target 25 documents may make it possible for such rules to be specified as an integral part of the source-amending (or drafting-script-amending) unit, for possible variations in structure of document content that may be made by a user to a target document, or a displayed document generated therefrom. 30 [0026] According to an embodiment of an aspect of the present invention, there is provided customising means for use by a user interface to customise that interface for use with an electronic-document generation system, the user interface being operable to display to a user a document comprising at least one portion identifier corresponding to a portion of that document and being further operable to permit the user to make an 35 amendment to the displayed document, the customising means comprising obtaining means operable, following such an amendment to said portion of the displayed 7 document, to obtain the portion identifier and information about said amendment from the user interface for use by the electronic-document generation system, [0027] Tho ucor intrftoco may, for example, la u urnputim karrmina running a user 5 application capable of displaying a document and capable of permitting a user to amend the document. For example, the displayed document may be a document formatted for compatibility with Microsoft Word ", and the user application may be Microsoft WordT. The customising means may be implemented in hardware or software, The customising means may be a software module for use with such a user 10 application. [0028] Such customising means preferably comprises communicating means operable to communicate the obtained portion identifier and the information to the electronic-document generation system. 15 [0029] According to an embodiment of an aspect of the present invention, there Is provided a user interface for use with an electronic-document generation system, the user interface comprising: display means operable to display to a user a document comprising at least one portion identifier corresponding to a portion of that document; 20 amending means operable to permit the user to make an amendment to the displayed document; and obtaining means operable, following such an amendment to said portion of the displayed document, to obtain the portion Identifier and information about said amendment for use by the electronic-document generation system. 25 [0030] Such a user interface preferably further comprises communicating means operable to communicate the obtained portion identifier and said information to the electronic-document generation system. [0031] According to an embodiment of an aspect of the present invention, there is 30 provided source-amending means for use with an electronic-document generation system, the system being operable to employ a content source comprising document content and a logic source comprising logic to generate a target document by evaluating said logic in dependence upon data, and being further operable to cause the target document or another electronic document generated therefrom to be displayed 35 to a user, and being further operable to permit the user to make an amendment to the displayed document, the source-amending means comprising amending means 8 operable, whon uuch an amendment other than a change to said data is made to the displayed document, to effect an equivalent amendment to a corresponding portion of the content source and/or the loqic source. 5 [0032] According to an ombodiment of an aspeol. uF [hi present invention, there is provided an electronic document expressed in a markup language comprising a plurality of elements, each element of the plurality of elements comprising an element identifier distinct from all element identifiers of that document. The markup language may be XML. Such a document may be stored on a storage medium, or may be 10 embodied in printed form, for example on paper. [0033] According to an embodiment of an aspect of the present invention, there is provided an electronic-document generation system comprising: generation means operable to employ a drafting script to generate a target document by evaluating logic 15 expressed within said drafting script in dependence upon data stored in a data source; a user interface operable to cause the target document or another electronic document generated therefrom to be displayed to a user, said user interface being further operable to permit the user to make an amendment to the displayed document; and drafting-script amending means operable, when such an amendment other than a 20 change to said data is made to the displayed document, to effect an equivalent amendment to a corresponding portion of the drafting script. [0034] According to an embodiment of an aspect of the present invention, there is provided a computer-implemented method for use in an electronic-document 25 generation system, the method comprising; employing a content source comprising document content and a logic source comprising logic to generate a target document by evaluating said logic in dependence upon data; displaying the target document, or another electronic document generated therefrom, to a user; permitting the user to make an amendment to the displayed document; and when such an amendment other 30 than a change to said data is made to the displayed document, effecting an equivalent amendment to a corresponding portion of the content source and/or the logic source. [0035] According to an embodiment of an aspect of the present invention, there is provided a computer-implemented method for generating a target document, the 35 method comprising: accessing a drafting script comprising document content and logic for generation of said target document, said drafting script comprising at least one 9 portion identified by a portion identifier, the or each said pvi uli, bunj Ispui isIble for the generation of a corresponding portion of said target document; employing said drafting script to generate said target document by evaluating said logic in dependence upon data: and including in each said portion of the target document the portion 5 identifier of the corresponding portion of the drafting script, or a portion identifier generated therefrom. [0036] According to an embodiment of an aspect of the present invention, there is provided a target document generated by a computer-implemented method of: 10 accessing a drafting script comprising document content and logic for generation of said target document, said drafting script comprising at least one portion identified by a portion identifier, the or each said portion being responsible for the generation of a corresponding portion of said target document; employing said drafting script to generate said target document by evaluating said logic in dependence upon data; and 15 including in each said portion of the target document the portion identifier of the corresponding portion of the drafting script, or a portion identifier generated therefrom. [0037] According to an embodiment of an aspect of the present invention, there is provided a computer-implemented method for customising a user interface of an 20 electronic-document generation system, the user interface being operable to display to a user a document comprising at least one portion identifier corresponding to a portion of that document and being further operable to permit the user to make an amendment to the displayed document, the method comprising: following such an amendment to said portion of the displayed document, obtaining the portion identifier and information 25 about said amendment for use by the electronic-document generation system. [0038] According to an embodiment of an aspect of the present invention, there is provided a computer-implemented user interface method for use with an electronic document generation system, the method comprising: displaying to a user a document 30 comprising at least one portion identifier corresponding to a portion of that document; permitting the user to make an amendment to the displayed document; and following such an amendment to said portion of the displayed document, obtaining the portion identifier and information about said amendment for use by the electronic-document generation system. 35 10 [0039] According to an embodiment of an aspect of the present invention, there is provided a computer-implemented method for use by an electronic-document generation system, the system being operable to employ a content source comprising duuurriei oritent and a logic source comprising logic to generate a target document 5 by evaluating said logic in dependence upon data, and being further operable to cause the target document or another electronic document generated therefrom to be displayed to a user, and being further operable to permit the user to make an amendment to the displayed document, the method comprising: when such an amendment other than a change to said data is made to the displayed document, 10 effecting an equivalent amendment to a corresponding portion of the content source and/or the logic source. [0040] According to an embodiment of an aspect of the present invention, there is provided a computer-implemented method for use in an electronic-document 15 generation system, the method comprising: employing a drafting script to generate a target document by evaluating logic expressed within said drafting script in dependence upon data stored in a data source; displaying to a user the target document or another electronic document generated therefrom; permitting the user to make an amendment to the displayed document; and when such an amendment other 20 than a change to said data is made to the displayed document, effecting an equivalent amendment to a corresponding portion of the drafting script. [00411 According to an embodiment of an aspect of the present invention, there is provided a computer-readable storage medium storing a computer program which, 25 when executed on a computer of an electronic-document generation system, causes the system to: employ a content source comprising document content and a logic source comprising logic to generate a target document by evaluating said logic in dependence upon data; display the target document, or another electronic document generated therefrom, to a user; permit the user to make an amendment to the 30 displayed document; and when such an amendment other than a change to said data is made to the displayed document, effect an equivalent amendment to a corresponding portion of the content source and/or the logic source. [0042] According to an embodiment of an aspect of the present invention, there is 35 provided a computer-readable storage medium storing a computer program for generating a target document which, when executed on a computer of an electronic- 11 document generation system, causes the system to: access a drafting script comprising rlociumnt content and logic for gonomfinn of 'Said tarudy ducuiiint, s:,d drafting script comprising at least one portion identified by a portion identifier, the or each said portion being responsible for the generation of a corresponding portion of 5 said target document; employ said drafting script to generate said target document by evaluating said logic in dependence upon data; and include in each said portion of the target document the portion identifier of the corresponding portion of the drafting script, or a portion identifier generated therefrom. 10 [0043] According to an embodiment of an aspect of the present invention, there is provided a computer-readable storage medium storing a computer program for customising a user interface of an electronic-document generation system, the user interface being operable to display to a user a document comprising at least one portion identifier corresponding to a portion of that document and being further 15 operable to permit the user to make an amendment to the displayed document, the computer program, when executed on a computer of the user interface, causing the user interface to: following such an amendment to said portion of the displayed document, obtain the portion identifier and Information about said amendment for use by the electronic-document generation system. 20 [0044] According to an embodiment of an aspect of the present invention, there is provided a computer-readable storage medium storing a computer program which, when executed on a computer of a user interface, causes the user interface to: display to a user a document comprising at least one portion identifier corresponding to a 25 portion of that document; permit the user to make an amendment to the displayed document; and following such an amendment to said portion of the displayed document, obtain the portion identifier and information about said amendment for use by the electronic-document generation system. 30 [0045] According to an embodiment of an aspect of the present invention, there is provided a computer-readable storage medium storing a computer program for use by an electronic-document generation system, the system being operable to employ a content source comprising document content and a logic source comprising logic to generate a target document by evaluating said logic in dependence upon data, and 35 being further operable to cause the target document or another electronic document generated therefrom to be displayed to a user, and being further operable to permit the 12 user to make an amendment to the displayed document, the computer program, when executed on a computer of the system, causing the system to: when such an amendment other than a change to said data is made to the displayed document, effect an equivalent amendment to a corresponding portion of the content source and/or the 5 logic source. [0046 According to an embodiment of an aspect of the present invention, there is provided a computer-readable storage medium storing a computer program which, when executed on a computer of an electronicj-document generation system, causes 10 the system to: employ a drafting script to generate a target document by evaluating logic expressed within said drafting script in dependence upon data stored in a data source; display to a user the target document or another electronic document generated therefrom; permit the user to make an amendment to the displayed document; and when such an amendment other than a change to said data is made to 15 the displayed document, effect an equivalent amendment to a corresponding portion of the drafting script. [0047] According to an embodiment of an aspect of the present invention, there is provided an electronic-document generation system for generating a target document, 20 the system comprising: an interpreter operable, during generation of said target document, to interpret at least one instruction of a predetermined type, the or each said instruction referring to data and identifying a content item for use in generating said target document; a first includer operable, for the or each said instruction, to include the identified content item or content derived therefrom in a portion of said target 25 document; an assigner operable to assign a first status or a second status different from said first status to the or each said portion of the target document in dependence upon said data; and a second includer operable, for each said portion of the target document, to include additional information in said target document indicative of whether the portion concerned has been assigned said first status or said second 30 status. [0048] The or each said instruction is preferably expressed (written/defined) in a markup language, for example in XML The additional information may optionally comprise a colour or another symbol. For example, the portion concerned (or content 35 within the portion concerned) may be coloured with one colour to indicate the first status, and another colour to indicate the second status. Alternatively, or additionally, the portion concornod may include or be assoteiak~d will une symbol to Indicate the first status, and aoitr symbol to indicate the second status. [0019] Such a 0yotom preferably furti, uumipiibs: a user Interface operate to 5 display the target document, or a document generated therefrom, in a first mode in which any such portion having said second status is included in the displayed document, or in a second mode in which any such portion having said second status is excluded from the displayed document Preferably, the user interface is operable, in said first mode, to include any such additional information in the displayed document 10 and, in said second mode, to exclude any such additional information from the displayed document. Preferably, the user interface is operable to include any such portion having said first status in the displayed document in both said first mode and said second mode. 15 [0050] Accordingly, it will be appreciated that the system may be employed to display a "draft" document (in the first mode), in which portions that will not be included in a "final" document (in the second mode) because of the current data, but which are optional portions and could be selected to be included in the final document by changing the data, are indicated to the user, Similarly, it will be appreciated that the 20 system may be employed to display a "draft" document (in the first mode), in which portions that will be included in a "final" document (in the second mode) because of the current data, but which are optional portions and could be selected as not to be included in the final document by changing the data, are indicated to the user. The user may then chose to change the data, by following a link or another such device in the 25 displayed document, so as to change the status of a portion of the document, If desired. [0051] Such a system preferably further comprises a tester operable, for the or each said instruction, to test the data concerned against a condition defined by logic, 30 wherein said assigner is operable, for the or each said instruction, to assign said first status to the corresponding portion if the data concerned satisfies the condition concerned, and to assign said second status to the corresponding portion if the data concerned does not satisfy the condition concerned, Preferably, the logic for the or each instruction is expressed (written/defined) in its respective instruction. 35 14 100-2] Thu intorproter io Drefivalily iilmblP, rilrina I Qnrston ot coid target document, to interpret a group of at least two said instructions. In that case, the system may comprise a tester operable, for each said instruction of the group in turn, to test the data concerned against a condition defined by logic, wherein said assigner is 5 operable to assign said first status to the portion corresponding to the instruction whose data first satisfies its condition, and to assign said second status to the or each other said portion. It will be appreciated that the group of instructions may relate to a group of portions of which only one should be given the first status, i.e. because only one should be included in the "final" document. Preferably, the logic for each instruction of 10 the group is expressed (written/defined/presented/included) in its respective instruction. [0053] The system preferably comprises a further includer operable to include a link in said target document, said link being operable to access a data-changing device for use in changing the data to other data, for example from current working data to 15 alternative data. [0054] The data employed by the system may comprise a composite data item being an instance of a composite data type. Further, the system may comprise a data accessing unit operable to employ a predetermined definition of said composite data 20 type to access said composite data item for use by at least one of said interpreter and said includers. [0055J According to an embodiment of an aspect of the present invention, there is provided an electronic-document generation system for generating a target document, 25 the system comprising: an interpreter operable, during generation of said target document, to interpret at least one instruction of a first type and at least one instruction of a second type, each said Instruction referring to data and identifying a content item for use in generating said target document; a first includer operable, for the or each said instruction of the first type, to include the identified content item or content derived 30 therefrom in a corresponding portion of said target document, and, for the or each said instruction of the second type, to include the identified content item or content derived therefrom in a corresponding portion of said target document or to not include any such content in the target document in dependence upon the data concerned; an assigner operable, for the or each said portion corresponding to one of said instructions of the 35 first type, to assign a first status or a second status different from said first status to that portion in dependence upon said data, and, for any portion corresponding to one of 15 said instructions of the second type, to assign said first status to that portion; and a second includer operable, for the or each said portion corresponding to one of said instructions of the firct typo, to include additional Information iin baid tiiytt document identifying that portion as having said first status or said second status, but, for any 5 portion corresponding to one of said instructions of the second type, to not include such additional information in said target document [0056) It will be appreciated that instructions of the first type and the second type can be used selectively to control which possible optional portions of a target document will 10 be included in that target document with such additional information irrespective of the data, and which will only be included in the target document if the data satisfies one or more conditions. This is advantageous, because complex target documents may have a large number of possible optional portions, and including them all with the additional information would create an overly complex target document. That is, an author 15 designing a script, e.g. a drafting script, for use by such a system can select whether to employ an instruction of the first type or of the second type, and can therefore control the complexity of the target document generated therefrom. [0057] Each said instruction is preferably expressed (written/defined) in a markup 20 language, for example in XML, [0058J The additional information may comprise a colour or another symbol. For example, the portion concerned (or content within the portion concerned) may be coloured with one colour to indicate the first status, and another colour to indicate the 25 second status. Alternatively, or additionally, the portion concerned may include or be associated with one symbol to indicate the first status, and another symbol to indicate the second status. [0059] Such a system preferably further comprises a user interface operable to 30 display the target document, or a document generated therefrom, in a first mode in which any such portion having said second status is included in the displayed document, or In a second mode in which any such portion having said second status is excluded from the displayed document. Further, such a user interface is preferably operable, in said first mode, to include any such additional information in the displayed 35 document and, in said second mode, to exclude any such additional information from the displayed document. Preferably, the user interface is operable to include any such 16 portion IaviIIu tsaid first status In the displayed document in both said first mode and said second mode. [0060] Accordingly, it will be appreciated that the system may be employed to display 5 a "draft' document (in the first mode), in which portions that will not be included in a "final" document (in the second mode) because of the current data, but which are optional portions and could be selected to be included in the final document by changing the data, are indicated to the user. Similarly, it will be appreciated that the system may be employed to display a "draft" document (in the first mode), in which 10 portions that will be included in a "final" document (in the second mode) because of the current data, but which are optional portions and could be selected as not to be included in the final document by changing the data, are indicated to the user. The user may then chose to change the data, by following a link or another such device in the displayed document, so as to change the status of a portion of the document, if 15 desired. [0061] Such a system preferably further comprises a tester operable, for the or each said instruction of the first type, to test the data concerned against a condition defined by logic, wherein said assigner is operable, for the or each said instruction of the first 20 type, to assign said first status to the corresponding portion if the data concerned satisfies the condition concerned, and to assign said second status to the corresponding portion if the data concerned does not satisfy the condition concerned. Preferably, the logic for the or each instruction of the first type is expressed (written/defined) In its respective instruction. 25 [0062] Preferably, such a system comprises a further includer operable to include a link In said target document, said link being operable to access a data-changing device for use in changing said data to other data, for example from working data to alternative working data, 30 [0063] The data employed by such a system may comprise a composite data item being an instance of a composite data type. further, such a system may further comprise a data-accessing unit operable to employ a predetermined definition of said composite data type to access said composite data iten for use by at least one of said 35 interpreter and said includes.

17 [0064] According to an embodiment of an aspect of the present invention, there is provided an electronic-document generation system for generating a target document, the system comprising: an interpreter operable to interpret an instruction of a predetermined type, said instruction referring to working data and identifying a content 5 item for use in generating said target document; a first includer operable, in dependence upon said data, to either include or not include said content item or content derived therefrom in said target document; and a second includer operable to include additional information in said target document, said additional information being indicative of how a change of said working data to alternative working data would affect 10 the content and/or structure of the target document. [00651 The instruction is preferably defined (written/expressed/presented) in a markup language, for example in XML. The first includer is preferably operable to only include said content item or said content derived therefrom if said working data 15 satisfies a condition defined by logic. The logic is preferably defined (written/expressed/presented) in said instruction. Such a system preferably comprises a further includer operable to include a link in such a target document, the link being operable to access a data-changing device for use in changing said working data to said alternative working data. 20 10066] The data employed by such a system may comprise a composite data item being an instance of a composite data type. Further, such a system may further comprise a data-accessing unit operable to employ a predetermined definition of said composite data type to access said composite data item for use by at least one of said 25 interpreter and said includes, [0067] According to an embodiment of an aspect of the present invention, there is provided a computer-implemented method for generating a target document, the method comprising; interpreting at least one instruction of a predetermined type, the or 30 each said instruction referring to data and identifying a content item for use in generating said target document; for the or each said instruction, including the identified content item or content derived therefrom in a portion of said target document; assigning a first status or a second status different from said first status to the or each said portion of the target document in dependence upon said data; and for 35 each said portion of the target document, including additional information in said target 18 document indicative of whether the portion concerned has been assigned said first status or said second status. [0068] According to an embodiment of an aspect of the present invention, there is 5 provided a computer-implemented method for generating a target document, the method comprising: interpreting at least one instruction of a first type and at least one instruction of a second type, each said instruction referring to data and identifying a content item for use in generating said target document; for the or each said instruction of the first type, including the identified content item or content derived therefrom in a 10 corresponding portion of said target document; for the or each said instruction of the second type, including the identified content item or content derived therefrom in a corresponding portion of said target document or not including any such content in the target document in dependence upon the data concerned; for the or each said portion corresponding to one of said instructions of the first type, assigning a first status or a 15 second status different from said first status to that portion in dependence upon said data; for any portion corresponding to one of said instructions of the second type, assigning said first status to that portion; and for the or each said portion corresponding to one of said instructions of the first type, including additional information in said target document identifying that portion as having said first status or said second status, but, 20 for any portion corresponding to one of said instructions of the second type, not including such additional information in said target document. [0069] According to an embodiment of an aspect of the present invention, there is provided a computer-rimplemented method for generating a target document, the 25 method comprising: interpreting an instruction of a predetermined type, said instruction referring to working data and identifying a content item for use in generating said target document; in dependence upon said data, either including or not including said content item or content derived therefrom in said target document; and including additional information in said target document, said additional information being indicative of how 30 a change of said working data to alternative working data would affect the content and/or structure of the target document. [0070] It will be appreciated that embodiments of aspects of the present invention also extend to electronic documents produced, or producable, by method aspects of. 35 the present invention disclosed herein. It will further be appreciated that such electronic documents may be embodied in an electronic file stored on a computer- 19 readable storage medium, in printed form for example on paper, as a signal on a carrier, or in any other form. [0071] According to an embodiment of an aspect of the present invention, there is 5 provided a computer-readable storage medium storing a computer program which, when executed on a computer of an electronic-document generation system, causes the system to: interpret at least one instruction of a predetermined type, the or each said instruction referring to data and identifying a content item for use in generating a target document; for the or each said instruction, include the identified content item or 10 content derived therefrom in a portion of said target document; assign a first status or a second status different from said first status to the or each said portion of the target document in dependence upon said data; and for each said portion of the target document, include additional information in said target document indicative of whether the portion concerned has been assigned said first status or said second status. 15 [0072] According to an embodiment of an aspect of the present invention, there is provided a computer-readable storage medium storing a computer program which, when executed on a computer of an electronic-document generation system, causes the system to: interpret at least one instruction of a first type and at least one 20 instruction of a second type, each said instruction referring to data and identifying a content item for use in generating a target document; for the or each said instruction of the first type, include the identified content item or content derived therefrom in a corresponding portion of said target document; for the or each said instruction of the second type, include the identified content item or content derived therefrom in a 25 corresponding portion of said target document or not include any such content in the target document in dependence upon the data concerned; for the or each said portion corresponding to one of said instructions of the first type, assign a first status or a second status different from said first status to that portion in dependence upon said data; for any portion corresponding to one of said instructions of the second type, 30 assign said first status to that portion; and for the or each said portion corresponding to one of said instructions of the first type, include additional information in said target document identifying that portion as having said first status or said second status, but, for any portion corresponding to one of said instructions of the second type, not include such additional information in said target document. 35 20 [0073] According to an embodiment of an aspect of the present invention, there is provided a computer-readable storage medium storing a computer program which, when executed on a computer of an electronic-document generation system, causes the system to: interpret an instruction of a predetermined type, said instruction referring 5 to working data and identifying a content item for use in generating a target document; in dependence upon said data, either include or not include said content item or content derived therefrom in said target document; and include additional information In said target document, said additional Information being indicative of how a change of said working data to alternative working data would affect the content and/or structure 10 of the target document. [0074] According to an embodiment of an aspect of the present invention, there is provided an electronic-document generation system operable to generate a target document by executing a program and at least one subroutine in dependence upon 15 data, wherein the content and/or structure of said target document is dependent upon said data. [0075] The program and said subroutine(s) are each preferably defined (expressed/presented/written) in a markup language, for example in XML. The 20 program and said subroutine(s) are further preferably each defined (expressed/presented/written) in a drafting script accessible by the system. The or at least one of the subroutines may actually be said program, such that the program is executed at least twice during such generation. 25 [0076] The system is preferably arranged such that: at least one of said program and said at least one subroutine refers to document content for inclusion in said target document during such generation; and the system is operable to include said document content in the target document in dependence upon said data during said generation. 30 [0077] The system is preferably arranged such that: at least one of said program and said subroutine(s) refers to a rule for evaluation based on said data during such generation, said rule specifying how the content and/or structure of at least a part of said target document should depend upon said data; and the system is operable to 35 evaluate said rule during said generation and to generate said part of the target document in dependence upon a result of said evaluation.

21 [0078] The program is preferably a function declaring at least one parameter for passing said data thereto. Further, the system is preferably arranged such that: the program is a function declaring at least one parameter; and the system is operable, 5 during such generation, to: set the or each parameter of said program to a value of at least part of the data based upon predetermined parameter-setting information; and execute the program in dependence upon the or each set parameter. The predetermined parameter-setting information may be held in a setting script accessible by the system, and that setting script may be defined (expressed/presented/written) in 10 a markup-ianguage, for example in XML. [0079] Similarly, the or each said subroutine is preferably a function declaring at least one parameter for passing some or all of said data thereto. Further, the system is preferably arranged such that: the or each said subroutine is a function declaring at 15 least one parameter; said program and said subroutine(s) are configured such that the or each said subroutine is designated by at least one calling instruction defined (expressed/presented/written) in said program or in the or one of the subroutines; each said calling instruction comprises parameter-settng information for setting the or each parameter of the designated subroutine to a value, or part of a value, referred to within 20 the program or subroutine defining (expressing/presenting) that calling instruction; and the system is operable, during such generation and for the or each said subroutine, to: set the or each parameter of the subroutine concerned in dependence upon the parameter-setting information of the calling instruction designating that subroutine; and execute the subroutine concerned in dependence upon the or each set parameter. At 25 least one said value referred to within the program or within one of said subroutines may be referred to by referring to a declared parameter. [0080] The program and the subroutine(s) may be configured such that, during said generation, at least one said subroutine is executed at least twice, and such that the 30 content and/or structure of parts of said target document generated by respective executions of that subroutine differ from one another. [0081] The system may be arranged such that: at least one of said program and said subroutine(s) expresses a recursive call instruction designating that program or 35 subroutine and a recursion-terminating condition; and the system is operable, during such generation, to execute that program or subroutine recursively until said recursion- 22 terminating condition is satisfied. Further, the systems rrTaiy be H±rrariged such that the generation comprises the execution of the program and at least two subroutines, and wherein at least one of the subroutines is configured to call at least another one of the subroutines, 5 [0082] Each subroutine may be executed while suspending execution of the preceding program or subroutine in a nested fashion. Alternatively, the system may be operable to execute one or more such subroutines simultaneously. 10 [0083] The data employed by such a system may comprise at least one composite data item, the or each composite data item being an instance of a respective composite data type. Further, the program (or, similarly, one or more of the subroutines) may comprise a function declaring a typed parameter for passing a value thereto, and the system may thus be operable, during such generation, to; set the typed parameter to a 15 value of the or one of the composite data items of the same type, or to a value of a component par of the or one of said composite data items of the same type, in dependence upon parameter-setting information; and execute said program in dependence upon the set parameter. 20 [0084] The target document Is preferably generated (written/defined) in a markup language, such as XML. Optionally, the target document is in a format suitable for displaying with a word-processing application, For example, the target document may be in any one of an RTF, an HTML, a PDF, and a Microsoft-Word format. The target document, or a document generated therefrom, may be a formatted text document, a 25 structured document, a structured text document or any combination thereof. [00851 According to an embodiment of an aspect of the present invention, there is provided a computer-implemented method for generating a target document, the method comprising generating the target document by executing a program and at 30 least one subroutine in dependence upon data, wherein the content and/or structure of the target document is dependent upon said data. [0086] According to an embodiment of an aspect of the present invention, there is provided a computer-readable storage medium storing a computer program for 35 generating a target document which, when executed on a computer of an electronic document generation system, causes the system to generate the target document by 23 executing a program and at least one subroutine in dependence upon data, wherein the content and/or otructure of said target dotumi i pirv d ihlueideIt upon said data. [00871 According to an embodiment of an aspect of the present invention, there is 5 provided an electronic-document generation system comprising: data-accessing means operable to employ a predetermined definition of a composite data type to access a composite data item being an instance of said composite data type from a data source; and generation means operable to employ a drafting script written in a markup language to generate a target document by evaluating logic in dependence upon said 10 accessed composite data item. [0088] The predetermined definition may comprise an expression definition for use in expressing the data item in said target document. For example, the logic may specify that the data item should be expressed (presented) in said target document, and the 15 generation means may, in that case, employ the expression definition during generation of said target document to express said data item in the target document. [0089] Such a composite data item may represent, for example, a person or a company. Such an expression definition may thus define how that person or company 20 should be represented in the document. For example, the expression definition may provide that, in the case of a company, the company's name and address and registration number should be presented, possibly in a defined format, when that company is expressed in the target document. Alternatively, the expression definition may provide that, in the case of a company, only the company's name should be 25 presented, possibly in a defined format, when that company is expressed in the target document. [0090] According to an embodiment of an aspect of the present invention, there is provided a computer-implemented method for generating a target document, the 30 rnethod comprising: employing a predetermined definition of a composite data type to access a composite data item being an instance of said composite data type from a data source; and employing a drafting script written in a markup language to generate the target document by evaluating logic in dependence upon said accessed composite data item. 35 24 [0001] According to an ef all aspect of the present invention, there is provided A compLIter-4rdable storago modium storing a computer prony~iai wihiul, when executed on a computer of an electronic-document generation system, causes the system to: employ a predetermined definition of a composite data type to access a 5 composite data item being an instance of said composite data type from a data source and employ a drafting script written in a markup language to generate a target document by evaluating logic in dependence upon said accessed composite data item. [0092] According to an embodiment of an aspect of the present invention, there is 10 provided an electronic-document generation system, comprising: a configuration unit which accesses a predetermined document-specific script for generating a target document and which, based on information contained within the predetermined document-specific script,: (i) identifies a default-data container comprising default data for said target script; (ii) generates a working-data container and populates that 15 container with said default data; (iii) identifies a data-obtaining unit operable to obtain working data for said target document from a data source other than said default-data container, and stores the obtained working data in the working-data container; (iv) identifies a drafting script comprising document content and logic for generation of said target document, said drafting script declaring parameters for applying data to said 20 drafting script; and (v) binds parameters of said drafting script to data items stored in said working-data container; and a generation unit which employs said drafting script to generate said target document by applying data stored in said working-data container to said drafting script based on said binding and by evaluating said logic in dependence upon said applied data 25 [0093] The data employed by such a system may comprise at least one composite data item, the or each said composite data item being an instance of a respective composite data type. 30 [0094] Such a container may comprise any entity that may store data, Such storage may be temporary. semi-permanent or permanent. For example, such a container may be embodied by: a computer-readable storage medium, such as a disk; a computer file stored in/on such a storage medium; a computer program by itself; and/or a relational database. 35 25 [0095] According to an embodiment nf an aspect of the present invention, there is provided a computer-implemented method for generating a target document, the method comprising: accessing a predetermined document-specific script for generating the target document and, based on information contained within the predetermined 5 document-specific script,: (i) identifying a default-data container comprising default data for said target document; (ii) generating a working-data container and populating that container with said default data; (iii) identifying a data-obtaining unit operable to obtain working data for said target document from a data source other than said default-data container, and storing the obtained working data in the working-data container; (iv) 10 identifying a drafting script comprising document content and logic for generation of said target document, said drafting script declaring parameters for applying data to said drafting script; and (v) binding parameters of said drafting script to data items stored in said working-data container; and employing said drafting script to generate said target document by applying data stored in said working-data container to said drafting script 15 based on said binding and by evaluating said logic in dependence upon said applied data. [0096] According to an embodiment of an aspect of the present invention, there is provided a computer-readable storage medium storing a computer program which, 20 when executed on a computer of an electronic-document generation system, causes the system to; access a predetermined document-specific script for generating a target document and, based on information contained within the predetermined document specific script,: (i) identify a default-data container comprising default data for said target document; (ii) generate a working-data container and populate that container 25 with said default data; (iii) identify a data-obtaining unit operable to obtain working data for said target document from a data source other than said default-data container, and store the obtained working data in the working-data container; (iv) identify a drafting script comprising document content and logic for generation of said target document, said drafting script declaring parameters for applying data to said drafting script; and (v) 30 bind parameters of said drafting script to data items stored in said working-data container; and employ said drafting script to generate said target document by applying data stored In said working-data container to said drafting script based on said binding and by evaluating said logic in dependence upon said applied data. 35 [0097j It will be appreciated that system aspects, or features thereof, are applicable equally to method and computer program aspects (and to any other aspects of the 26 present invention), and vice versa. It will be appreciated that although aspects of the present invention are directed to a computer-readable storage medium storing a computer program, aspects of the present invention also extend to such computer programs by themselves. It will also be appreciated that embodiments 5 of aspects of the present invention also extend to electronic documents produced, or producable, by method aspects of the present invention disclosed herein. It wil] further be appreciated that such electronic documents may be embodied in an electronic file stored on a computer-readable storage medium, in printed form for example on paper, as a signal on a carrier, or in any other form. 10 According to an embodiment of an aspect of the present invention, there is provided an electronic-document generation system for generating a target document, the system including: an interpreter which, during generation of said target document, interprets at least one instruction of a predetermined type, the or each said instruction 15 referring to data and identifying a content [tem for use in generating said target document; a first includer which, for the or each said instruction, includes the identified content item or content derived therefrom in a portion of said target document even when a value of the data that the instruction refers to indicates that the 20 content item or the content derived therefrom is to be excluded from the target document; an assigner which assigns a first status, indicating that the content item concerned or the content derived therefrom is to be included in the target document, or a second status, indicating that the content item concerned or the 25 content derived therefrom is to be excluded from the target document, to the or each said portion of the target document in dependence upon the data that the instruction concerned refers to; and a second includer which, for each said portion of the target document, includes additional information in said target document indicative of whether the 30 portion concerned has been assigned said first status or said second status. According to an embodiment of an aspect of the present invention, there is provided an electronic-document generation system for generating a target document, the system including: 26a an interpreter which, during generation of said target document, interprets at least one instruction of a first type and at least one instruction of a second type, each said instruction referring to data and Identifying a content item for use in generating said target document; 5 a first includer which, for the or each said instruction of the first type, includes the identified content item or content derived therefrom in a corresponding portion of said target document, and which, for the or each said instruction of the second type, includes the identified content item or content derived therefrom in a corresponding portion of said target document or does not 10 include any such content in the target document in dependence upon the data concerned; an assigner which, for the or each said portion corresponding to one of said instructions of the first type, assigns a first status, indicating that the content item concerned or the content derived therefrom is to be included in the target 15 document, or a second status, indicating that the content item concerned or the content derived therefrom is to be excluded from the target document, to that portion in dependence upon the data that the instruction concerned refers to, and which, for any portion corresponding to one of said instructions of the second type, assigns said first status to that portion; and 20 a second includer which, for the or each said portion corresponding to one of said instructions of the first type, includes additional information in said target document identifying that portion as having said first status or said second status, but which, for any portion corresponding to one of said instructions of the second type, does not include such additional information in said target document. 25 According to an embodiment of an aspect of the present invention, there is provided an electronic-document generation system for generating a target document, the system including: an interpreter which interprets an instruction of a predetermined type, said instruction referring to working data and identifying a content item for use in 30 generating said target document; a first includer which, in dependence upon said data, either includes or does not include said content item or content derived therefrom in said target document; and 26b a second includer which includes additional information in said target document, said additional information being indicative of how a change of said working data to alternative working data would affect the content and/or structure 5 of the target document. According to an embodiment of an aspect of the present invention, there is provided a computer-implemented method for generating a target document, the method including: interpreting at least one instruction of a predetermined type, the or each 10 said instruction referring to data and identifying a content item for use in generating said target document; for the or each said instruction, including the identified content item or content derived therefrom in a portion of said target document even when a value of the data that the instruction refers to indicates that the content item or the 15 content derived therefrom is to be excluded from the target document; assigning a first status, indicating that the content item concerned or the content derived therefrom is to be included in the target document, or a second status, indicating that the content item concerned or the content derived therefrom is to be excluded from the target document, to the or each said portion 20 of the target document in dependence upon the data that the instruction concerned refers to; and for each said portion of the target document, including additional information in said target document indicative of whether the portion concerned has been assigned said first status or said second status. 25 According to an embodiment of an aspect of the present invention, there is provided a computer-implemented method for generating a target document, the method including: interpreting at least one instruction of a first type and at least one instruction of a second type, each said instruction referring to data and identifying 30 a content item for use in generating said target document; for the or each said instruction of the first type, including the identified content item or content derived therefrom in a corresponding portion of said target document; 26c for the or each said instruction of the second type, including the identified content item or content derived therefrom in a corresponding portion of said target document or not including any such content in the target document in 5 dependence upon the data concerned; for the or each said portion corresponding to one of said instructions of the first type, assigning a first status, indicating that the content item concerned or the content derived therefrom is to be included in the target document, or a second status, indicating that the content item concerned or the content derived 10 therefrom is to be excluded from the target document, to that portion in dependence upon the data that the instruction concerned refers to; for any portion corresponding to one of said instructions of the second type, assigning said first status to that portion; and for the or each said portion corresponding to one of said instructions of the 15 first type, including additional information in said target document identifying that portion as having said first status or said second status, but, for any portion corresponding to one of said instructions of the second type, not including such additional information in said target document. According to an embodiment of an aspect of the present invention, there is 20 provided a computer-implemented method for generating a target document, the method including: interpreting an instruction of a predetermined type, said instruction referring to working data and identifying a content item for use in generating said target document 25 in dependence upon said data, either including or not including said content item or content derived therefrom in said target document; and including additional information in said target document, said additional information being indicative of how a change of said working data to alternative working data would affect the content and/or structure of the target document. 30 Due to the complex nature of documents automation systems, the present invention is intended to include any combination of any of the aforementioned aspects of the present invention, and/or any of the aforementioned preferable 26d features thereof. The present invention is also intended to include combinations of the features disclosed below in the detailed description of the invention. DETAILED DESCRIPTION OF THE INVENTION 5 Reference will now be made, by way of example, to the accompanying drawings, in which: Figure 1 is a schematic diagram of a system embodying the present invention Figure 2 is a schematic diagram for use in explaining the relationship 10 between the role of the author, and the role of the user. Figure 3A is a schematic overview useful for explaining the general methodology employed by the system of Figure 1. Figure 38 is a schematic diagram to illustrate how the system of Figure 1 is organised. 15 Figure 4 is a flow diagram of a method for use by the system of Figure 1. Figures 5 to 12 show typical interface screens of a user interface of the Figure 1 system. Figure 13 is a schematic diagram illustrating the use of document-type scripts. 20 Figure 14 shows an example of an interface screen generated by the Figure 1 system. Figure 15 shows an example of an interface screen generated by the Figure 1 system. Figure 16 is a schematic diagram of a question-session script. 25 Figures 17A and 17B show interface screens for explaining array-creator controls. Figures 18A and 1 B show interface screens for explaining reference chooser controls.

27 Figures 19A and 19B show interface screens for explaining set-chooser controls. Figure 20 is a schematic diagram for illustrating the function of an object manager, and the role of a container adapter. Figures 21 and 22 are schematic flow diagrams to illustrate how a user might interact 5 with the system of Figure 1. SYSTEM OVERVIEW [001001 Figure 1 is a schematic diagram of a system 1 embodying the present 10 invention. The system 1 comprises a system server 2, an author terminal 4, and a user terminal 6 connected to one another via a network 8. It will be appreciated that the network 8 could be any type of network, for example the Internet, a LAN (local area network) or a mobile cellular network, or any combination thereof. Accordingly, the system server 2, the author terminal 4 and the user terminal 6 could all be located in 15 the same place or spread across the world. Equally, the functionality of the system server 2, the author terminal 4 and user terminal 6 could be provided on a single computing device. [00101] As can be appreciated from Figure 1, the system 1 is designed to interact with 20 two different types of people, namely users and authors. The authors use the author terminal 4 to tailor the system 1 to be able to generate a certain type of document or suite of documents. The users in turn use the user terminal 6 to employ the system so tailored to generate such documents or suites of documents. 25 (00102] Because users of the system 1 may typically use the system to generate complex legal documents, the system 1 has been designed such that such a legal expert, for example a lawyer, can act as an author and tailor the system as mentioned above. Further, because the functionality of the system 1 is provided in software (i.e. by a computer program or suite of programs), that software has been adapted to 30 employ scripts to produce the required documents. Authors, such as lawyers, can produce such scripts with only minimal training, as compared to training such authors in the art of software design. [00103] It will be appreciated that in one embodiment of the present invention, the 35 system 1 could comprise two system servers 2, a "staging" server and a "live" server. The staging server could be used to test out new scripts or software modifications in a 2a test environment, such new scripts or software modifications being transferred to the live server following acceptance of those scripts or software modifications, Accordingly, it can be possible for users to employ the system 1 without being affected by ongoing maintenance and updates until that maintenance and those updates are proven to be 5 satisfactory. [00104J In particular, the system 1 employs XML (Extensible Mark-up Language) scripts. XML is hardware and software neutral, and accordingly it can be used to create data that different applications running on different devices can work with. An 10 understanding of XML can be obtained from http://www.w3.orq/XML and/or from http://www.w3schools com/lxmi/xmnl whatis. asp. [00105] Figure 2 is a schematic diagram for use in explaining the relationship between the role of the author, and the role of the user. Figure 2 shows an author 12, an author 15 interface 14, a script repository 16, a data repository 18, a user 20, and a user interface 22, The author interface 14, the script repository 16, the data repository 18, and the user interface 22 may all be implemented in the system server 2 of Figure 1, or may be distributed across the system 1. 20 [00106] In general, the author 12 can use the author interface 14 to generate scripts for use in generating documents. In particular, the author interface comprises a script editing system for use in generation of such scripts. The system 1 employs different types of scripts, as will be explained later. The author interface 14 stores the generated scripts in the script repository 16. The author may also generate default 25 data so that it is possible for documents to be generated using that default data, i.e. without requiring any working data to be supplied to the system 1. The default data is stored in the data repository 18. 100107] The user 20 can employ the user interface 22 to access scripts in the script 30 repository 16, and data in the data repository 18, to generate documents. As will be explained later, the user can also store working data in the data repository 18 in place of or in addition to the default data, and can also store amended scripts in the script repository 16 in place of or in addition to the scripts provided by the author. 35 [00108] Figure 3A is a schematic overview useful for explaining the general methodology employed by the system 1. The schematic overview of Figure 3A 29 Presents an XL drafting script 30 (as one type of script used by the system 1), an XL instance document 32 an output document 34, a data container 36, a default data source 38 and a data-obtaining unit 40, The XML drafting script 30 could, for example, be stored in the script repository 16, and similarly the data container 36 and 5 the dofault-data source 38 could, for example, be stored In the data repository 18. [00109] The XML drafting script 30 is used to generate the XML instance document 32. The XMIL instance document 32 is then converted into an output document so as to be viewed by a user of the system 1. The output document may be in any format, 10 for example in en HTML format for viewing with a web browser, or in a Microsoft Word Format (e.g. WordML) for viewing with Microsoft Word. It will of course be appreciated that the system i may be employed to produce the output document 34 directly from the drafting script 30, thereby avoiding production of the XML instance document 32, for example if Only one type of output document 34 (such as HTML) is required. 15 [001101 The XML drafting script 30 contains document content and logic for use in generating the instance document 32. The drafting script declares parameters for use in passing data thereto from the data container 36. That data may be used both to form document content and to evaluate the logic contained within the XML drafting 20 script 30 during generation of the XML instance document 32. [00111] The data stored in the data container 36 may be default data obtained from the default-data source 38. Alternatively, or additionally, the data stored in the data container 36 may be working data obtained by (or made available by) the data 25 obtaining unit 40 from a source other than the default-data source 38, and stored in the data container 36 for use in generating the XML instance document 32. [00112] The data-obtaining unit 40 preferably employs an XML question-session script (not shown) to elicit the working data from a user by prompting the user to answer one 30 or more questions during a question session. An XML questionsession script is another type of script employed by the system 1, and the use of such scripts is described in greater detail below. The data-obtaining unit 40 may be employed to obtain working data from a source other than a user, In that case, it may serve as an adapter to allow data to be sourced from an external system, for example from a 35 database. The use of the data-obtaining unit 40 as an adapter is described in greater detail below.

30 [00113] Figure 3A also shows two feedback routes 42 and 44. The function of such feedback routes is explained in greater detail below, however it is to be understood that the system 1 provides a link (feedback route 42) from the output document 34 to the 5 data-obtaining unit 40 to enable the user to amend the data stored in the data container 36, and a link (feedback route 44) from the output document 34 to the XML drafting script 30 to enable the user to amend the drafting script 30 itself. It will be appreciated that the system 1 therefore enables a user to view the output document 34 in a familiar form (e.g. as a Microsoft Word document) and to amend that document as he sees fit, 10 such amendments being recorded by means of the feedback routes 42 and 44 such that a further generation of the XML instance document 32 and the output document 34 will produce the output document 34 in the amended form. [00114] Although not clearly shown in Figure 3A, it is to be understood that the XML 15 instance document 32 may be generated from more than one XML drafting script 30, or from a single XML drafting script 30 calling a number of XML sub-drafting scripts. It is also to be understood that the data for use in generating the XML instance document 32 may be obtained from more than one data container 36, and that the data stored in those data containers 36 may have been sourced from two or more default-data 20 sources 38, and/or obtained by two or more data-obtaining units 40. This feature of the system 1 is explained in greater detail below. [00115] Figure 3B is a schematic diagram to illustrate how the system 1 is organised so as to benefit from the hardware- and software-neutral nature of XML scripts. 25 Question-session scripts and drafting scripts written in XML specify their content without being committed to any particular rendering technology. For example, questions defined by a question-session script could be rendered in HTML or by controls on Windows Forms or by any other medium which allows the expression of structured controls. Correspondingly, drafting scripts are used to generate instance 30 documents in an XML form which may be rendered in HTML, in Word, in RTF, in PDF or in any other structured document format. [00116] This independence from rendering technologies is represented in the way that software employed by the system 1 is organised. The software is organised into three 35 layers; a top layer 43, a middle layer 44, and a bottom layer 45. The bottom layer 45 communicates with the script and data repositories 16, 18. The middle layer 44 31 implements the core services such as that of generating an instance document 32 from a drafting script 30 and a set of data from a data container 36. The top or 'front' layer 43 is responsible for rendering the results of the services provided by the middle layer 44 for presentation to a user 20. Thus, for example, this top layer 43 might render 5 questions of a question-session script as a page of HTML controls, or might render a generated instance document 32 as a Microsoft Word output document 34, or as an HTML page. [00117] The layers 43, 44, and 45, are organised so that lower layers are independent 10 of higher layers. That is, the (data access) bottom layer 45 can work without the (service) middle layer 44. And, more importantly, the data-access layer 45 and the service layer 44 can work without the (rendering) top layer 43. Accordingly, the rendering layer 43 can employ different rendering components while the rest of the system (layers 44 and 45) stays the same. For example, so far as the service 44 and 15 data-access 45 layers are concerned, the task of generating a document is exactly the same whether the document is to be rendered as an HTML page or rendered as a Microsoft Word document. [00118] Figure 4 is a flow diagram of a method 48 for use by the system 1. The 20 method 48 represents the interaction between a user and the system 1. The un shaded boxes of Figure 4 represent choices presented to the user by the system 1 and actions carried out by the user in response to those choices. The shaded boxes (steps $6, 310 and S16) represent actions carried out by the system 1 in response to the user's actions. The operation of method 48 assumes that an author has already 25 tailored the system 1 for use by the user as discussed above. [00119] In discussing the method 48, reference will be made to Figures 5 to 12, which show typical interface screens of a user interface of the system 1 during operation of the method 48. Those interface screens are shown displayed by a web browser, 30 however it is understood that the system 1 could use other means to interact with a user. [00120] The system 1 is organised to support a deal which represents a transaction in which more than one document is required. Accordingly, a user using the system 1 for 35 the first time will typically start at step $2 of the method 48 by creating a new deal. Figure 5 shows an interface screen 50 which may be seen by a user using the system 32 1 for the first time. The interface screen 50 presents a list of existing deals 52 to the user, In this case, as the user is using the system for the first time, no such deals are listed, The interface screen 50 also allows the user to carry out a number of actions, namely to create a new deal 54, delete a deal 56, and to seek system help 58. At step 5 S2 of the method 48, the user may thus elect to create a new deal 54. [00121] Al step S4, the user may select a deal template to create a new deal. Figure 6 shows an interface screen 60 which may be presented to the user at this stage. Interface screen 60 presents the user with three possible deal templates. In the 10 present case, the "Share purchase deal template" has been selected 62. A field 64 at the bottom of interface screen 60 allows the user to enter a name for the deal. In the present case, the name "Share purchase 1" has been entered. A button 66 marked "Create Deal" allows the user to effect his selection. 15 [00122] In response to the user's selection at step S4 the method 48 proceeds to step 36 at which the system I creates default deal-wide data, i.e. some initial default data that which will be appropriate for deals of the selected type, regardless of what documents are eventually generated. Figure 7 shows an interface screen 70 which may be presented to the user at this stage. interface screen 70 identifies the 20 previously-generated deal as "Share purchase 1" at box 72, and provides a list 74 of the generated documents that are part of that deal. At this stage, no such documents have yet been generated, and as such none are listed. The interface screen 70 allows the user to carry out a number of actions of which one is to create a new document 76. In response to the user selecting the "create a new document" action 76, the method 25 proceeds to step 58. [00123] At step S8 the user is presented with a list of possible document types suitable for the selected deal. Figure 8 shows an interface screen 80 which may be presented to the user at this stage. The interface screen 80 lists types of document that 30 are available, and in the present case it can be seen that the "List of Parties" type has been selected 82. The interface screen 80 allows the user to enter a name for the selected document in box 84, and further allows the user to initiate the creation of a document of the selected type by clicking the "create document" button 86. 35 [00124] In response to the user selecting the desired type of document at step S8, the method proceeds to step S10 in which the system 1 creates a data container for the 33 desired document, and populates that container with default data for that document, i.e. some initial default data which will be appropriate for that type of document. The method 48 then proceeds to step S12. 5 [00125] At step S12, the user is presented with a choice. Figure 9 shows a typical interface screen 90 which would be presented to the user at this stage. The user may want either to see the document generated using the default data, or to provide some initial working data up-front. Accordingly, the interface screen 90 presents two options amongst others. The user can select the "Q & A" tab 92 (as shown) and proceed by 10 answering a series of questions 94, or the user can select the "Draft" tab 96 (as hidden) and proceed by viewing the document as generated using the default data. [00126] If, at step 312, the user decides that he would prefer to provide some initial data up-front, the method 48 proceeds to step 814 and the user is then typically 15 prompted by a series of questions, which are relevant to the desired document, to provide the working data by answering those questions. The working data is then stored in a container or a set of containers for use in generating the desired document. The method then proceeds to step 316 in which the desired document is generated using the working data as provided by the user, and optionally some of the default data 20 where the user has not answered all questions relevant to the desired document. [00127] If, at step S12, the user chooses to see the document generated using the existing data, in this case using the default data without providing some initial working data up-front, the method proceeds to step S16 and the desired document is created 25 from the default data (as no working data is yet available) and is presented to the user. Figure 10 is a typical interface screen 100 which would be presented to the user at this stage. The interface screen 100 is similar to the interface screen 90 except that the "Draft" tab 96 has been selected and the desired document is shown in box 102. A list of clauses 104 is also shown to give the user an overview of the structure of the 30 generated document. The method then proceeds to step S18 in which the user can choose to modify the generated document. [00128] The generated document displayed to the user in box 102 contains devices to enable the user to modify or add to the data that is used in the generation of that 35 document. One example of such a device is a link that takes the user to questions whose answers provide the data employed in the document's generation. If the user 34 chooses to modify the generated document in this way, the method proceeds through steps S14 and $16 again to regenerate the document using the modified or new data. The method then returns to step S1 8. 5 [00129] The generated document displayed to the user in box 102 also contains devices to enable the user to modify or add to the document content that is not dependent on the data used in the generation of that document. That is, the system 1 allows the user to amend the drafting script itself, One example of such a device is a link that records such an amendment made by the user and effects a corresponding 10 amendment in the appropriate drafting script. If the user chooses to modify the generated document in this way, the method proceeds to step S16 again to regenerate the document using the modified drafting script and the existing data. The method then returns to step S18. 15 [00130] Once the user has finished working on the generated document for the time being, the user can decide in step S20 whether he would like to add another document to the existing deal. If he decides that another such document is required, the method returns to step 58 to allow the user to select another document type (or the same type again) from a list such as that shown in Figure 8. If, however, the user decides that no 20 such further document is required, the method terminates at step S22. [00131] Once a deal has been created, a user may return to it and add new documents to it, or modify documents that have previously been created within it. Accordingly, method 48 allows a user to begin at step S30 and proceed to step S32. 25 At step 332, the user can select an existing deal. Figure 11 is a typical Interface screen 110 which would be presented to the user at this stage. The interface screen 110 is similar to the interface screen 50 of Figure 5, except that the list of existing deals 52 now lists the previously-created deal "Share purchase 1". Accordingly the user can choose that deal to be worked upon, 30 [00132] At step 534 the user can decide whether he would like to create a new document for the deal, or work on an existing document. In the former case, the method proceeds to step 38, and in the latter case the method proceeds to step S36. 35 [00133] Figure 12 is a typical interface screen 120 which would be presented to the user at step S36. The Interface screen 120 is similar to the interface screen 70 of 35 Figure 7, except that the list 74 of the generated documents that are part of the "Share purchase 1" deal now lists the previously-generaled document "List of Parties". The method then proceeds to step S12. 5 [00134] Data that has been entered for one document may be relevant to several other documents in the deal. The system 1 ensures that where this is the case, the data is shared so that it does not have to be entered more than once. This feature of the system 1 is explained in greater detail below. 10 [00135 As previously mentioned, the system 1 of Figure 1 is adapted to be driven by scripts, particularly XML scripts that have been prepared by an author. The types of scripts employed by the system 1 can be divided into three main types, namely document-type scripts, drafting scripts, and question-session scripts. Other types of scripts are employed by the system 1, however these three types are the most 15 important types used by the system 1. [00136] Document-type scripts are used to associate drafting scripts with question session scripts and to bind the data variables used by the drafting script to values of data elicited from users (or made available from other sources), or to default data. 20 Accordingly, document-type scripts also identify a container of default data. As already mentioned, question-session scripts are employed by the data-obtaining unit 40 to elicit data from users and drafting scripts are employed to generate documents in dependence upon the elicited data and/or default data based on the methodology discussed above. 25 [00137] When a user chooses a type of document to create, for example during step S4 of the method 48, the system activates a document-type script for that type of document. Accordingly, based on the content of that document-type script, a drafting script, a question-session script, and a container of default data are identified. Figure 30 13 is a schematic diagram illustrating this principle. Figure 13 shows an interface screen 130 similar to the interface screen 60 of Figure 6, in which a user has selected a confidentiality agreement as the desired type of document. In response to this action, the system 1 has activated a document-type script 132 for confidentiality agreements. Accordingly, a question-session script 134, a drafting script 136, and a 35 container 138 of default data for the question session script 134 have been identified. One reason for separating the scripts into document-type, question-session, and 36 drafting scripts is to enable the same drafting script to be used with different question session scripts in different contexts. [00138] In order to understand the system I further, it is necessary to consider the 5 scripts that it employs in more detail. QUESTION-SESSION SCRIPTS [00139] As mentioned above, a question-session script is employed by the system 1 to 10 elicit data from a user, Typically, such a question-session script is used to define questions that are put to a user so as to obtain working data therefrom. It will be appreciated that a fundamental requirement of the system 1 is to be able to handle data efficiently and accurately, and this feature of the system 1 will be considered alongside question-session scripts. 15 [00140] As question-session scripts need to be writable by an author (who may be a lawyer having only minimal knowledge of software design), the system 1 has been designed such that those scripts define the questions to be put to a user in a type of pseudo code that is easy enough for an author to read and interpret, but that contains 20 enough information for the system I to present the questions to the user. The system 1 employs XML question-session scripts, and a DTD (Document Type Definition) has been developed for those question-session scripts. The scripts are structured, medium-neutral specifications of controls for data input. Forms containing the controls can be rendered in HTML or in other formats and media as mentioned above. 25 [00141] The script element I below defines the wording of a question about the name of a buyer. It also suggests the type of control that should be used by any rendering agent when presenting the question, in this case the suggestion Is that the control should be one that allows the user to enter a line of text. 30 <question namc-"buyerName"> <captior>.What is the name of the buyer</caption <uiHint value&"inputLine"/ <answers> 35 <freeAnswer maxChars="512"/> <defaulIt>[Buyer]<default <(answers> </question> 37 [00142] The script element 2 below defines the wording of a question about the type of the buyer. It also suggests the type of control that should be used by any rendering agent when presenting the question. In this case the suggestion is that the control 5 should be one that allows users to make a choice between two options. <question name="huyerType"> <caption>Is the Buyer a company or a real pcrson?</caption> <uiHint va1ue="radioButtons"/> 10 <answers> <defhult>person</defaut> (2) <option caption="Ierson">person</option>(2 Caption caption="Company">company</opI ion> </answers> 15 </question> [00143] Each time a question-session script is used to elicit data from a user, a response container is created to hold that data. That is, when a question-session script executes and the user provides input, the data provided by the user (together, 20 normally, with some default data) is placed in a specifically-created container. These response containers are held in the data repository 18 as shown in Figure 2. 100144] It can already be seen that the system 1 may deal with types of data that have an inherent structure or hierarchy, as well as with pieces of data having no such 25 structure. The examples of data types provided above in the script extracts 1 and 2 of 'buyerName' and 'buyerType' illustrate some simple types of data having a minimal inherent structure or hierarchy. The system I is of course not restricted to data having such simple name-value structures. 30 [00145] The data items or objects that make up the data held in response containers are instances of types of data. An example of such a type of data is a "Person". That is, data defining a person is of a particular type because it has a particular structure and content, e.g. first name, second name, address. Other types of data employed by the system 1 include types which correspond to legal concepts, for example, 35 Obligations, Companies, Shares, etc. [00146] A particular type of data is defined by the named properties that the instances of that type possess, together with the types of those properties. For example, consider the data type 'Address'. This is defined as follows: 38 Address Simple line Simple line2 5 Simple Lown Simple posLeode [00147] This has four properties, namely line, line2, town, and postcode. Instances of each of those four properties are of type 'Simple'. The 'Simple' type has no properties 10 other than a text value. [00148] A further example of a data type is the "Person" type as mentioned above. The Person type is defined like this: 15 Person Simple firstNames Simple givenName Address address 20 (00149] That is, a person has the properties: firstNames, givenName and address. The firstNames and givenName properties are Simples, they just have a text value, but instances of the address property are of type Address as defined above. 25 [00150] Data items, or pieces of data, are instances of such data types, and it can be seen that such data types (and the instances of those types) can have a hierachical or tree structure. For example, an instance of Person data type corresponds to the following tree structure: 30 root of the Lree (the instance of Person) - firsta'ames: "John George" givenNames; "Smith" 35 address line: "1 Acacia Gardens" 40 -- ine2; --- town: "Someton" postcod: "ST1 1AA", 45 39 [00151] It can accordingly be seen that question-session scripts are employed to obtain data items which are instances of data types. The data obtained from each question-session script is stored in a corresponding container. As a result, each response container, in which data obtained by a particular question session is stored, 5 can be considered to be the root of an object tree whose immediate children are instances of these data types such as Persons, Obligations etc. Each data container can be embodied in an XML script form, and a DTD has been developed therefor. Such scripts for the persistent form of data elicited by question-session scripts, or obtained through other means, describe instances of data types from a hierarchical 10 data model. [00152] In view of the structured or hierarchical form of data types, such as "Person", the system 1 employs a generic script called a group-type script for each such data type to define a set of controls to elicit instances (data items) of the data type 15 concerned from a user. Each such set of controls is called a group type. The sets of controls are designed to have a hierarchical structure themselves, each being isomorphic with the structure of the corresponding data type. This enables the set of controls to be representative of the structure of the data that is being elicited. 20 [00153] The isomorphic relationship between the hierarchical structure of the data types and the hierarchical structure of the group types has a number of related benefits, Because an author of the system is provided with this information (i.e. that the isomorphic relationship should be maintained), the process of writing a group-type script for a new data type can become intuitive and systematic. That is, the job of the 25 author is made easier than if the group type could have any structure (i.e. such as a structure possibly bearing little relationship to the structure of the data type). This isomorphic relationship allows the author to follow a logical process to write a group type script, which process can be followed effectively for any data type regardless of its complexity. 30 [00154] This isomorphic relationship can also have similar benefits for the user. That Is, even when group types (sets of controls) become complex, it is still possible for a user to determine the relationship between the constituent controls of the set of controls because this Is represented by the hierarchical structure of that set of controls. 35 In short, the role of the user to provide the system 1 with data is made easier than if the 40 group type could have any structure (i.e. such as a structure possibly bearing little relationship to the structure of the data type). [00155] The group-type scripts, written based on this isomorphism, are preferably XML 5 scripts that are render-format neutral, re-usable, and customisable. Accordingly, they can be presented to a user using any technology (HTML, Windows Forms, etc). However, the group-type scripts define the hierarchical structure of the controls thus rendered, such that the structure of the data to be supplied can be deduced regardless of which technology is used to render the controls, Because the group-type scripts are 10 author-written, they are also editable by such an author, for example to perform customisation, i.e. without requiring a detailed knowledge of software design. [00156] A question-session script can reference a particular group-type script one or more times. Each time such a group-type script is referenced by a question-session 15 script, it can (as mentioned above) be customised for the situation in which it is to be used. For example, the group type (set of generic controls) for eliciting data of the type "Person" can be customised so as to elicit data for a particular type of person, such as a buyer or a seller. 20 [00157] In order to further explain the use of group-type scripts, the example of the "Person" data type will be used as follows. As stated above, the "Person" data type may be considered to have the following tree or hierarchical structure: 25 Person Simple firstNames - Simple givanNames Address address 35 --- Simple line --- Simple line2 Simple town Simple postoode 41 [00158] The "Person" group-type script is accordingly a definition for a "Person" group type, i.e a control whose purpose is to elicit data for a "Person" type of data object (data item). That is, the result of a user interacting with the control generated based on that group-type script is the creation or modification of a data object which is an 5 instance of this type, and whose property values (the actual data itself) have been supplied by the user. As discussed above, the group-type script is an XML script and is therefore independent of rendering technology. It is generic to that type of data (e.g. the "Person" type), customisable, and re-usable. The following script element 3 is an example of a "Person" group-type script which defines the "Person" group type (set of 10 controls) for the "Person" data type. <?xnl version-"1.0" eneoding="utf-S"?> <groupType btype- "ompracticallaw.btypes.Person" <questionMemnbe name=" givenNames"> 15 <caption>First Name(s)</caption> Cuil-int value="inputLinc"/> <sizelfint value-"5"/> <answers> <freeAnswer maxChars="32"/ 20 <default>[Givcn Nanes]</default> </answers> </qucstionMembner> (3) <questionMember narme="familyName"> <caption>Surname</caption> 25 <uihint value="inputLine"/> <sizeHint valur.-"5"/> <answrs> <freeAnswer maxChurs="32"/> <defaul>[Fanily Name]</dcfault> 30 </answers> </questionMember> <group Member name="address" typcida"practicallaw.com/pit/Address" /> <groupType> 35 [00159] The script element 3 specifies that the group type that it defines is for the Person data type (the full name of the Person type is 'com.practicallaw.btypes. Person'). It then defines a series of questions, one for each property of the Person data type. [00160] The script element 3 also contains a reference to the Address group-type 40 script in the penultimate line. The reference is to the Address group-type script, i.e. to the group type, and not to the Address data type per se. The Address group-type script, which is not shown, will accordingly specify that the group type that it defines is 42 for the Address data type, and it will define questions for each of an address's properties (i.e. line, line, town and postcode). [00161] Accordingly, it can be seen that a group-type script may be referenced by 5 other group-type scripts (as the example of the Person group-type script referencing the Address group-type script shows). A group-type script may also be referenced in a question-session script, creating in the question session generated based on that question-session script a particular group of questions. For example, a question session script can create a Person group of questions by including the following script 10 element 4. <group name="buyer" typeid-"practicallaw.com/pit/Person"/> (4) [00162] The system 1, when interpreting the script element 4, will generate a group of 15 questions based on the Person group type. Figure 14. shows an example of an interface screen 140 which the system 1 could generate based on the script element 4. The interface screen 140 shows a group of questions Fendered in HTML. It will of course be appreciated that the same group of questions could also be rendered using another technology, for example by generating a control on a Windows Form, It will 20 also be appreciated that even within a single rendering technology, such as HTML, it is possible for the same control to be rendered in different ways. [00163] The interface screen 140 shows a set of questions 142, or in this case a set of indications as to what data is required, and a set of input fields 144 in which the 25 relevant data is required. The input fields are shown displaying default data, however this default data can of course be replaced with actual working data. The hierarchy of the "Person" data object (data item) being edited is reflected in the numbering that has been used for the individual data objects that make up the "Person" data object. 30 [001641 At the point in a question-session script or other script where a group-type script is referenced, such as by the script element 4 above, further information can be provided so as to customise the group of questions (group type) produced from it. For example, one could suppose that an author may want to customise the script element 4 so that the generated control of Figure 14 appears labelled with the term ' Buyer rather 35 than simply the term 'Person', and so that it is labelled with 'Buyer's Address' rather 43 than with "Address". The following script element 5, as compared to the script element 4, would achieve this customisation of the group type. <group name="buyer" typeid="praticallaw.com/pit/Prson"> 5 <caption>Buyer</caption> <iiclude~iroup name-"address" bcfore="NOTHING"> <caption>Buyer's address<caption> (5) </includeGroup> <andAll/> 10 </group> [00165] The system 1, when interpreting the script element 5, will generate a group of questions based on the Person group type, but with the customisation discussed above. Figure 15 shows an example of an interface screen 150 which the system 1 15 could generate based on the script element 5. The interface screen 150 shows a group of questions rendered in HTML. It will be appreciated that the interface screen 150 of Figure 5 is identical to the interface screen 140 of Figure 4, except that it is labelled with the term 'Buyer' rather than simply the term 'Person', and except that it is labelled with 'Buyer's Address' rather than with "Address". 20 [001661 It will be appreciated that each time a group-type script is referenced by a question session it could be customised in a different way, or at least it could be used to obtain a different data item. This is illustrated by the following script element 6 in which the same group-type script is referenced twice (without any customisation) with 25 the data object obtained from the first reference being assigned to the name "buyer", and the data object obtained from the second reference (to the same set of questions) being assigned to the name "seller. That is, the same group type can be instanced in many question sessions, arid, indeed may be instanced many times in the same question session. 30 <group namc="buyer" typeid="practicallawcoom/pit/Person"/> (6) <group narne="seller" typoid'n"practicallaw.com/pit/Person"/> 35 [00167] A question-session script employed by the system I normally contains more than just a list of references to group-type scripts. It normally contains a 'definitions' section and at least one 'page logic' section. Figure 16 is a schematic diagram of a question-session script 160. The question-session script 160 comprises a definitions section 162, and three page logic sections 164. The definitions section 162 defines 44 user controls (for example by referencing group-type scripts as discussed above), and the page logic sections 164 each define individual pages or interface screens that will be presented to the user. Box 94 of Figure 9 is an example of such an interface screen or page. 5 [00168J Each page logic section will typically list controls from the definitions section, as being the controls that should appear on its page. Those page logic sections that are for pages that are part of a series of pages will typically specfy what the 'next' page will be by referring to another page logic section. It will be appreciated that the same 10 control defined in the definitions section can appear on several pages. Whether a control appears on a particular page or what the contents of the 'next' page will be can be the subject of 'if.. then...' logic dependent on the data input by the user. [00169] The definitions in the definitions section generally contain customised 15 references to group-type scripts as described above. As already mentioned, this is possible because a group-type script is an independent, sharable definition of a control which can be used by several question-session scripts and which can be customised differently for each use. 20 [00170] Each such page logic section is a named executable block of the question session script that's executed just before the user sees the page which it defines. The definitions section specifies the page logic section that defines 'first' page, so just before the user sees the corresponding first page, that page logic section is executed to determine which controls the user will see (and what the content is of the link to the 25 'next' page). Then, when the user has entered data and clicked 'next', the page logic specified as being for the next page is executed, and again what the user will see on the page is determined. Because XML is used, the various pages are independent of the technology (e.g. HTML) used to render the controls. 30 [00171] The structure of a question-session script can be better understood with reference to the following script elements 7, 8, and 9. <firstpage name="start"/ 35 <question name--"deedOrAg"> <caption> Is the document a deed or an agreement?<;caption> <ui lint value="ist"/> 45 <sizeHint value"- 1"!> <answers> <defaul>deed<dfault> <option captionr"Deed">deed</option> 5 <option caption="Agreenent">agreement<optionii. </answers> <question> <group name="buycr" typeid="practicallaw.cor/pitperson-"> (7) <caption>Buyer</caption> 10 <includeGroup name="address" befotc="NOTHING"> <caption>Buyes address</cap[ion> </includeGroup> <andAlL/> </group> 15 <group name=" seller" typid&-"practicallaw.com/pit/prson> <caption>Seller<captioni> <ineludcGroup naine-"address" before="NOTHNG"> <caption>Seller's address</caption> </includcGroup> 20 <andAll/ </group> <group name=" witness" typeidr"practicallaw.con/pic/Person"> <oaption>Witness<c/caption> CincludeGroup name-"address" before="NOTfI-NC"> 25 <caption>Witness's address</caption> </includcGroup> <andAll/> </group> 30 .00172] Script element 7 is an example of a definitions section of a question-session script. It can be seen that script element 7 states that the first page logic section that should be executed should be a page logic section called "start". It can also be seen that script element 7 continues to define a number of controls by referring to (and customising) group-type scripts. 35 <da:pageLogic> <da:controlRefs> <dia; ontroiReft"deedorAg"<C/da:controlRef> (8) </da:controlRefs> 40 <da:setNextPage>"secondPae"</da setNextPage <da:pageLogic>x [00173] Script element 8 is an example of the page logic section called 'start', and 45 accordingly it would be the first-executed page logic section by a question-session script containing the script element 7. Script element 8 states that the next page logic section that should be executed should be a page logic section called "secondPage".

46 <da:pageLogi c> <da:controlRefs> <da:controlRet$"buyer"</da.controlRof 5 <da~controlRek."seller"<da:controlRef> <da:choice> <da:ifd("dedOrAg").equals("deedt")<-/da~if> (9) <da:select> <da:controlRe-"witness"</da:colitroil~er 10 <da:select> </da:choice> </dca:controlRefs> <da:setNextPage></da: setNextPage> </da;pageLogic> 15 [00174] Script element 9 is an example of the page logic section called 'secondPage'. Accordingly, it would be the page logic section executed after the script element 8. It can be seen by the inclusion of the "if.. .then.." logic at lines 5 to 10 of the script element 9 that the "witness" group of questions will only be displayed on this page if the 20 answer to the question displayed based on the script element 8 is "deed". [00175] It can be seen that the script element 9 does not state a next page, I.e, the penultimate line reads "<da:setNextPage></da:setNextPage>" with nothing between the two tags. Accordingly, the page generated based on the script element 9 is the last 25 page in the sequence of pages. [00176] In some instances, an author will come across a situation in which no data type exists within the system 1 for a particular case in point. The set of data types used in the system 1 constitutes its data model. This data model may change but must 30 change slowly and in a very controlled way. The reason for this is that drafting scripts, question-session scripts and group-type scripts are all dependent on the data model, or on particular sub-sets of the model. Accordingly, making a change to the data model may involve changing many scripts. 35 [00177] In contrast, the data model is generally not dependent on scripts. Accordingly, in general it is not possible for authors to modify the data model. However, when working on scripts in a particular domain, for example in a particular area of the law, which is relatively uncharted (i.e. for which not many scripts have yet been developed), it is desirable that authors be able to experiment with different ways of organising the 40 data types for that domain. However, it is also desirable that this experimentation does 47 not require authors to learn complex new techniques; ideally such experimentation should be possible using skills that authors already possess. [00178] Against this background, the system 1 has been designed to enable authors to 5 design and use trial structured data types before they become accepted data types. Authors are able to generate such trial data types without having to work on any elements other than the controls which render and elicit property values for those trial data types. In other words, the script editors can simply draft a script similar to a group type script to produce complex controls, and these complex controls contain enough 10 information for complex data types to be inferred from them. When the authors are satisfied with their design, the trial data type may be formally committed to the store of data types as an accepted data type. However, before the trial data type is formally committed, the authors may employ that trial data type in their question session scripts and drafting scripts. 15 [00179] Such trial data types are termed 'Protobos' (prototype business objects). A Protobo can be defined by nothing other than a reference to a group-type script, and so the group-type script determines the properties of the trial data type. 20 [00180] For example, suppose that an author is creating scripts for a financial domain, and realises that data is needed about interest defaults. He can create a Protobo for this data type called 'InterestDefault'. As mentioned above, this Protobo can simply specify a group type (i.e a group-type script). The script element 10 below is an example of a group-type script for this Protobo. 25 <xnml version-" L -)" encoding="utf-8"?> <group'Fype blype="com.practicallaw.btypes~financial.lntorostDefault"> <questionMember name-"includeLateProvision"> ccaption>Include a provision providing for interest on late payments?</caption 30 <ulint value="list"/> <sizeint value=" 1'> <aalswers defaultl ttruc7</default> <option caption="Include">true<option> 35 <option caption="Do not inc1ude">false<option (10) answerer> <-/questionMcmber> <questionMember name="percentage"> <caption>The rate of interest on late payments</capt ion> 40 <uiflint value="inputLie"/> <sizel.Tint value="1"/ 48 Canswers>p <freeAnswer mnaxChars="10"> <defaujt>4%<default> c/answers> 5 </questionMembcr> <groupMCmber name="bankAddress" typeid&"praeticallaw.com/pit/Address" > <caption>Addrcss of banksc/caption> </groupMcmber> </groupType> 10 [00181] The Protobo based on the script element 10 will have the properties corresponding to the members of the group type that it defines, i.e. "includeLateProvision" and "percentage" will be "Simple" properties, and "bankAddress" 15 will be a properly of type "Address". It is to be noted that the script element 10 identifies the Protobo ("com-practicallaw.btypes.financial.InterestDefault") that uses the script element 10 itself to define its own properties. This apparent circularity is benign, and indeed is useful because it enables the Protobo eventually to be replaced by an accepted data type without having to amend the group-type script. 20 100182] It is desirable for an author of a question-session script to be able to allow a user to create data that represents a number of objects, where the number of objects is not known by the author in advance of the users input. For example, the number of parties involved in a deal depends on the details of the user's deal and cannot be 25 known by the author in advance of the user providing those details. [00183] It is also desirable for users only to have to enter data once for a deal, even if that data needs to be referred to in a variety of contexts by the documents in that particular deal. Therefore, it is desirable that the user should be able to assign a 30 particular role to a data object that has already been created. For example, the same company may be acting as attorney for two different parties to a deal, and it would be inconvenient to have to enter the details about the attorney twice. Also for example, the same person may be acting as a buyer with respect to one agreement and acting as a seller with respect to another. Again, the user will not want to have to enter the details 35 for that person more than once. [00184] Against this background, the system 1 has been adapted to handle three special types of data, which can be referred to as 'arrays' (for representing collections of data items whose size is only known at runtime), 'references' (for where a single 49 data object can be used for a number of different roles), and 'sets' (which are, effectively, a collection of references whose size is not known until runtime). Further, the system has been designed to employ generic controls which can be employed by authors of question-sessions scripts to elicit such data types. For arrays, there is a 5 generic 'array-creator' control. For references, there is a generic 'reference-chooser' control. For sets there is a generic 'set-chooser' control, These controls are generic enough to be used in all circumstances in which the corresponding data-types are required, they can be customised for particular question-session usages, and they are simple enough to handle such that non-technical question-session authors can design 10 question sessions (i.e. draft question-session scripts) which contain them. [00185] An author can specify, in a question-session script, that a question session should contain an array-creator control if there is a need to allow a user to create a collection of similar entities, and the user (i.e. not the author) determines the number of 15 entities that will be created. It will be appreciated that an author can also specify, in a group-type script, that an array-creator control should be generated based thereon (this is of course applicable to any type of control). An array-creator control might be useful, for example, to create data about the participants in a deal. In this case, the author might use the script element 11 below. 20 <array na me="participants" > <caption>List of dcal participants</caption> <designati on>participants</dcsignation> (11) <itnName>participant</iteinNa me> 25 <groupCcll typeid="practicallaw.com/pit/Person" /> </array> [00186] As can be seen from the script element 11, the array-creator control to be generated is called 'participants'. The use of this control, during a user's question 30 session, will create an array data object in the response container for that question session. The name of that array data object is also 'participants'. It is to be noted that the script element 11 contains a reference to a sub-element, in this case to a group type script. It is further to be noted that the group-type script referenced by the script element 11 is the "Person" group-type script. The effect of this reference is to ensure 35 that each array element is created using that group-type script, so that in this case the array is an array of Persons.

50 [00187J The script element 11 shows that the control for eliciting the array data type can be customised. In the case of the script element 11, this has been done by supplying a 'designation' which is the name of the collection as a whole, and an 'item name' which is used to label individual members of the array. The group type (specified 5 by the reference to the group-type script in the script element 11) used to edit members of the array may be customised for the context using the techniques already described above. [00188] Figure 17A shows an example of an interface screen 170 which the system 1 10 could generate based on the script element 11. The array-creator control shown on the interface screen 170 shows that there are already three members of the array. For example, the first member 171 is shown as being "Frank Smith". The array-control comprises a button 172 labelled "New participant" for enabling further members to be added to the array, and a button 173 labelled "Delete" for enabling existing members to 15 be deleted from the array. [00189] Each member of the array generated from the script element 11 is a data object of the "Person" data type and accordingly although only the name of each member is shown on the interface screen 170, it is to be understood that other data 20 (e.g. the address) for each member may have already been entered by a user. [00190] Figure 17B shows an example of an interface screen 175 which the system could generate in response to the user clicking a link from the listed name 171 ('Frank Smith'), It can be seen that the link has generated the group of questions defined by 25 the corresponding Person group type, and shows the data corresponding to Frank Smith. It will be appreciated that clicking the 'New participant' button 172 will also take the user to questions defined by the Person group-type script, but in this case showing the default answers. 30 [00191] An author can specify in a question-session script that a corresponding question session should contain a reference control if there is a need to allow a user to assign a particular role to a data object that is a member of a collection of objects (such as an array or set). Continuing the example discussed above, such a control could enable a user to select, from the list of deal participants, one of those participants as 35 being 'the buyer. In this case, the author might use the script element 12 below- 51 <refrcnce name="buyer"> <caption>Buycr</caption> (12) <rcferenceArray>participants</referenceArray> </reference> 5 [00192] The 'reference' element defined by the script element 12 contains a sub element which specifies a named array, in this case an array called 'participants', which may, for the sake of example, be considered to be the array of Persons defined by the script element 11 above. It can be seen that the reference-chooser control defined by 10 the script element 12 is called 'buyer. The employment of this control during a users question session will assign a selected deal participant to the role of 'buyer. [00193] From the perspective of drafting scripts (which are discussed in greater detail below) the reference-chooser control will generate a data item named 'buyer, and from 15 that perspective the situation will be indistinguishable from that in which a completely new Person object was created and provided with that name. [00194] Figure 18A shows an example of an interface screen 180 which the system 1 could generate based on the script element 12. The reference-chooser control 20 generated on the interface screen 180 shows that the first-named member "Frank Smith" of the array shown in Figure 17A has been chosen 181 to be the "buyer". The reference-chooser control comprises a button 182 labelled "Change" for enabling a different member of the array of participants to be chosen instead of "Frank Smith". 25 [00195] Figure 18B shows an example of an interface screen 185 which the system 1 could generate in response to the user clicking the "Change" button 182. It can be seen that this has brought up a control 186 listing the members of the array of participants. It is to be noted that the control shown employs radio buttons 187, such that only one member of the participants array can be chosen (or such that the user 30 can select that no answer is to be provided at present). [00196] It will be appreciated that particular members of an array will be used in a variety of situations. For example, in the generation of a particular document for a deal, one of the persons in the array may be identified by a reference as a party to that 35 document. It is valuable for a user to be able to link back to the array-creator control which defined the properties of an array member from wherever that array member is used. For example, it is advantageous to be able to link back from a generated 52 document to which a person is a signatory, to the definition of the properties of that person. The reason that the link is advantageous is that it enables a user to modify properties of the array member, or to add new information (for example to modify or add information about a person). [00197] However, the particular control that was used to create that array member is normally only identified by the position in the array of the member it was used create. Unfortunately, if members are removed from the array, or new members are inserted in the array this position may change. Accordingly, the system I orders members in an 10 array by their position in the sequence of additions to that array. This number does not change even if other members are added or removed from the array. Accordingly, the system 1 indexes arrays by this ordinal number - the 'add ordinal' - rather than the more conventional 'position' ordinal so as to ensure that the correct member of an array will be edited. 15 [00198] The data structure produced by a set-chooser control is in some respects similar to that produced by an array-creator control and in other respects similar to that produced by a reference-chooser control. It is similar to the data structure produced by an array-creator control in that, from the perspective of a drafting script (or certain other 20 controls), a set can be regarded as a collection of objects which can be iterated over as discussed above. However, a set employed by the system 1 is not a collection of actual objects, as an array is, but is instead a collection of references to objects. [00199] Such a set-chooser control could be useful when, for example, an author 25 wishes to enable a user to select, from a list of deal participants, a selection of those participants as being 'sellers' in a particular transaction, In that case, the author might use the script element 13 below. <answerSct name=" sellers"> 30 <caption>Sellers<caption> <designation>Sellers<designation> (13) CitemName>Seer</itemJName> <answerSetArray>participants</answerSetArray> </answerSetP 35 [00200] The 'answerSet' element defined by the script element 13 contains a sub element which specifies a named array, in this case the array called 'participants' 53 defined by the script element 11. The set-chooser control defined by the script element 13 is called sellere and the employment of this control during a user's question session will assign a number of selected deal participants to the role of 'sellers'. 5 [00201] From the perspective of drafting scripts (which are discussed in greater detail below) the set-chooser control will generate a collection named 'sellers' and from that perspective the situation will be indistinguishable from that in which a completely new array of Persons was created with that name. 10 [002021 Figure 19A shows an example of an interface screen 190 which the system 1 could generate based on the script element 13. The set-chooser control generated on the interface screen 190 shows that the second- and third-named members "Emily Brandon" and "Charles Brandon", respectively, of the array shown in Figure 17A have been chosen 191 to be the "sellers". The set-chooser control comprises a button 192 15 labelled "Change" for enabling a different selection of members of the array of participants made than the current one. [00203] Figure 19B shows an example of an interface screen 195 which the system 1 could generate in response to the user clicking the "Change" button 192, It can be 20 seen that this has brought up a control 196 listing the members of the array of participants, 11 is to be noted that the control shown employs check boxes 197, such that more than one member of the participants array can be chosen. DOCUMENT-TYPE SCRIPTS 25 [00204] One key feature of the system 1 is that users do not have to enter the same data twice when generating documents in a deal. Data that is pertinent to a particular document has to be entered only once. If the user returns to that document, the data entered will have been stored. Further, data that is pertinent to several documents, for 30 example to documents of a deal, only has to be entered once and the documents share the data; that is, the same data is utilised in generating all the documents to which it is relevant. Accordingly, changes to data must affect all of the documents which share that data. So, for example, a change to a party's address should be picked up by any document which lists that address, 35 54 [00205] Data which is shared between several documents in a deal is called 'deal-wide data'. Deal-wide data often (though not always) comprises collections of data items stored in arrays (as discussed above). An array of the names and details of all the parties to a transaction is an example of such deal-wide data. Other examples include 5 details of properties whose ownership is being transferred, details of subsidiary companies which are being sold along with a parent company, and details of leased units, amongst others, An example of deal-wide data that is not in data held in an array is a reference to a target company (e.g. a company being purchased) in a share purchase transaction (though the company data itself, rather than its identification as 10 the target through a reference, would normally be held in a shared array of other parties). [00206] One example of data that would not normally be treated as deal-wide data is data determining whether a particular document is to be signed as an agreement or as 15 a deed. Data such as this, which is pertinent to a particular document only, is called 'document-specific data. [00207] It is desirable for users to be able to select documents to include in a particular deal freely. It is further desirable that no predetermined restrictions should be placed 20 on a selection made by such a user. This is because which documents are required in a particular deal is typically dependent on circumstances peculiar to that deal, and it is not possible to predict in advance just what those circumstances will be. Therefore if a document-type is available in one type of deal, it is desirable to make it available in every type of deal. 25 [00208] It is also desirable to allow users to create documents outside the context of a deal, even if documents of that type may also be created within a deal. That is, users sometimes wish to create documents in a 'one-off ad-hoc mode. If a document-type is available in any type of deal, it is desirable to also make it available in a stand-alone 30 mode [00209] Accordingly, in the case where documents are being created within the context of a deal, the system 1 ensures that any new documents in the deal use the right data items. That is, data-variables used in drafting-scripts for new documents are 35 bound to the correct data objects in the existing deal-data. The system 1 can, for example, bind a variable 'soldCompany'. declared in a drafting script to represent a 55 company being sold in a deal, to deal-wide data elicited by a question-session script and referred to as 'target, 100210] The methodology employed by the system 1 to bind variables or parameters 5 declared in a drafting script to the correct data will be explained with reference to document-type scripts. A problem that is solved by this methodology is that different documents use different kinds of deal-wide data, so when a document is created and the data elicited for that document, there may be no deal-wide data generated yet which is of the right sort. Accordingly, the system creates that data when it is required, 10 and makes it available to any subsequent drafting script that requires that same data. The methodology employed by the system 1 also enables the binding to work even if a document is being created outside the context of a deal. [00211] Document-type scripts, as mentioned above, are authored scripts which 15 associate together question-session scripts, drafting scripts, and default-data containers (which may also be scripts), In the explanation and examples that now follow, it will be shown that a document-type script may specify and use a number of 'shared' document-type scripts (and thereby a number of 'shared' question-session scripts), and a number of data containers. Through this setup, it will be appreciated 20 that the document-type script can enable correct data binding to be achieved. It will also be appreciated that underlying this functionality is a system by which virtual object repositories (containers) are created from which data objects are locatable using a systematic object naming convention. The contents of those repositories (containers) are assembled on-demand. 25 [00212] A key aspect of the data-binding capability of the system 1 is based on an understanding of how drafting scripts are interpreted by the system 1. Drafting scripts are discussed in greater detail below, however for the benefit of the present explanation It is to be understood that drafting scripts are essentially program functions 30 that declare parameters (for the purpose of receiving data) and generate a document as their output. From this perspective, the data-binding capability of the system 1 is centred on assigning the right data values to the parameters of the drafting scripts. [00213] The function of document-type scripts in the system 1 will be considered by 35 reference to an example document-type script. The script element 14 below is an example of such a document-type script.

56 <da;docunent ype xn:lns:da-"http://practicalaw.com/plc/da"> <da:local idrcf="practicallawcoin/qs/qsetss_scripti"> <da:defiultData idrcf="practicallawcoim/qs/qsess script defaults" > 5 </da:iocal> <da:shared idref="practicallaw.com/dot/doctype2"> <da:shared idref-"practicallaw.com/dot/doctype3" /> <da:forDraftScript idref="practicallaw.contp/draft script1> <da:setParam name-"signType"> 10 d("signAs") <dasetParan> (14) <da:setParan name="soldCompany"> d("practicallaw.comlqs/qsess script2/target") /da:sorParan> 15 <da:setParam name="retailUnit"> d("shopDetails") <da:setParan> <da:forDraftScript </da:documentType> 20 [00214] As has been described, a document-type script associates together a question-session script, a drafting script and a set of default date. A 'da:Iocal' tag is used to specify the question-session script, the 'da:defaultData' tag is used to specify 25 the default data, and the 'da;forDraftScript' tag is used to specify the drafting script. A document-type script may also identify other document-types as providing deal-wide data, and it does that with the 'da:shared' tag. [00215] In the script element 14, it can be seen that the document-type script sets the 30 parameters of the drafting script 'draft script1. One parameter used in draftscripti is 'signType' which may be considered to determine whether the document generated from the drafting script 'draft scriptt' is to be executed as an agreement or a deed. The value of this parameter is drawn from the question-session script 'qsessscriptl' which is the question-session script associated directly with the present document-type script 35 of the script element 14, and is known as its local question-session script. This data is document-specific. Note that the parameter called 'signType' in the drafting script 'draft script' is set to the answer elicited by a control called 'signAs' in the question session script 'qsess-scriptl'. 40 [00216] A second parameter used in the drafting script 'draft scriptt' is 'soldCompany'. This parameter is being set to a value drawn from the data elicited from question session scripts specified in the document-type script 'doctype2', a document-type script 57 that has been declared here as shared. Although not shown, it may be assumed for the sake of example that the document-type script 'doctype2' specifies the question session script 'qsesss script' as its local question-session script, Thus, the question session script 'qsess_soript2' is available to the present document-type script of the 5 script element 14. The element in the present document-type script which sets the value of 'soldCompany' refers to the data obtained from the control called 'target' in the question-session script 'qsess script2' [00217] The third parameter used in the drafting script 'draft_.script1' is 'retailUnit'. This 10 parameter is set to the value of 'shopDetails' in the question-session script 'qsessscriptl'. Although this looks very similar to the document-specific data 'signType', the data in this case could be shared, and this possibility will now be explained. 15 [002181 In the script element 14, the question-session script 'qsess script' is the question-session script that Is the primary source of data for the document-type script of the script element 14, i.e. 'qsess-scriptl' is its 'local' question-session script. Amongst the data items that the question-session script 'qsess script' is responsible for producing is one called 'shopDetails'. The kind of scenario which this example is 20 intended to illustrate is where a deal involves a number of shops, but where the document that is to be produced is only concerned with an individual shop. For example, such a document might describe the leasing arrangements for a given shop. In other words, this example considers that 'shopDetails' is a reference to an object in an array, and the array which contains that object is an array of descriptions of shops. 25 Thus, in the present example, the corresponding control defined by the question session script 'qsess script' is a reference chooser, and when the user activates the present document-type script of the script element 14, one of the questions that he or she is asked involves selecting the shop which will be described in the document being created. 30 [00219] Continuing the present example, the details of all the various shops involved in the deal are part of the shared deal-wide data. Accordingly, the element in the question-session script 'qsess script' which defines the reference chooser will refer to this shared data. An example of that element is shown below as script element 15, 35 which may be considered to be pad of the question-session script 'qsess-scriptl'.

58 <reference name="shopDctails"> <caption>The store</caption> <referenceArray> (15) practicallawconVq/qsess_script3/shopDetailsArray") 5 </referenceArray> </reference> [00220] It is to be noted, from a study of the script element 15, that the array 'shopDetailsArray' from whose members the reference-chooser of the script element 10 15 will allow the user to select is not defined in the question-session script 'qsess scriptl. in this case, it is defined in question-session script 'qsess script3' [00221] Thus from the perspective of a document-type script which uses the question session script 'qsess script' as its 'local' question-session script (such as the 15 document-type script of the script element 14), the question-session script 'qsess-script3' is responsible for shared, deal-wide data. This is the reason that the document-type script of the script element 14 specifies the document-type script 'doc type' as shared data. This example of course assumes that the document-type script 'doc type3' specifies the question-session script 'qsess -script3' as its 'local' 20 question-session script. Accordingly, it will be appreciated that the document-type script of the script element 14 specifies the document-type script 'doctype3' as shared data because its local question-session script 'qsess script' uses data drawn from the question-session script 'qsessscript3'. 25 [00222] It will be noted that the document-type scripts of the system 1, as exemplified by the script element 14, specify another document type-script (e.g. doc-type3) in order to specify shared data, rather than another question-session script. There are two reasons for this formulation of document-type scripts. 30 [002231 Firstly, as explained above, question-session scripts define the controls used to create and modify data. However, in order to define a usable container of data, default data values are also to be provided, and the default data values are dependent on the type of document being created. These default data values are associated with question-session scripts in document-type scripts. 35 [00224] Secondly, it is almost always convenient to have a drafting script associated with a container of data, because the drafting script can be used to generate a document to view the data in that container. In most cases, that document will, in fact, be a document which is a necessary part of the deal concerned. However, even if the document is not strictly required as part of the user's output, it will nonetheless normally provide a useful descriptive report of the data in the corresponding container, For example, even if there were strictly no need for a document specifically listing all 5 the details of all the various shops involved in the above example deal (and any other information elicited by the question-session script 'qsessscript3'), it would almost certainly be quite useful to have this listing. [00225] The example described with respect to the script element 14 above has 10 demonstrated that a document-type script of the system 1 typically declares a 'local' question-session script (in the example above, this is 'qsess scriptl', a document-type script for any question-session script to which it itself refers using a structured object locator (in the example above, this is Illustrated by the 'target' reference), and a document-type script for any question-session to which its local question-session script 15 refers (in the example above, this is illustrated by its reference to 'doctype3'). However, any of the declared document-type scripts may themselves declare other document type scripts sources of shared data. Any particular document may thus be associated with a complex web of shared data. 20 [00226] As demonstrated by the script element 14, document-type scripts achieve the required binding of data to parameters in drafting scripts by specifying cross-references between various data containers. The underlying mechanism which enables cross references between data containers is a virtual data repository. In order to support this functionality, the system I employs a sub-system to enable access to objects stored in 25 a set of response containers, where each container is the product of a different question session. This sub-system is known as the 'object manager', [00227] The fundamental function of the object manager in the system 1 is to return data objects given an object locator (obloc), which may be a structured object locator. 30 Some oblocs are simple, and an example of such a simple obloc is the element 'signType' in the script element 14. Other oblocs are qualified by the name of a question session. An example of this type of obloc is the element practicallaw.com/qs/qsessscript2/target' in the script element 14. Qualified oblocs are known as 'remote oblocs'. The simple, or unqualified, oblocs are known as 'local' 35 oblocs.

60 [00228] When a user starts or returns to a deal, for example following step S2 or S30 of the method 48 of Figure 4, an object manager is initiated. Such an object manager operates on the basis of one active document, which has a corresponding drafting script and a corresponding local question-session script defined in the document's 5 document-type script. There is also a local response container, containing the data which is produced or edited from the local question-session script. Local oblocs return objects in the local response container. [00229] As well as the local response container, the object manager also makes 10 available a number of remote response containers. Objects in these containers are accessible only using remote oblocs. A more complete description of oblocs is provided below, [00230] Containers are added to the virtual data repository on-demand and are not 15 duplicated. That is, response containers are made available to an object manager just when the process of creating a deal is made aware of their necessity. So, for example, when a user chooses a new document to create and in effect selects a chosen document-type script to be executed, the containers corresponding to all of its shared document-type scripts are created, as are containers corresponding to what its shared 20 document-type scripts declare as shared, and so forth for the entire web of document type scripts thus associated with the chosen document-type script. However, if, during this process, it is found that a container for responses to a particular question-session script already exists, that response container it is not created. Question-session response containers are not duplicated. 25 [00231] Accordingly, if a document-type script newly chosen in a deal states that it requires a certain kind of question-session response to be stored in a response container, and another document-type script has already created a response of that kind, the newly chosen document-type script will use the data that already exists. For 30 example, if one document-type script declares its use of a shared list of parties, then when a document of that type is created, a list of parties will be generated. Then, when another document-type script is chosen which also declares its use of a shared list of parties, that other document-type script will use the list of parties that already exists. 35 [00232] It can accordingly be appreciated that the system 1 can employ the various scripts, in particular document-type scripts, and an object manager so as to enable 61 data to be shared to prevent users having to enter or modify the same data more than once. Further, the system 1 enables users to freely add documents of any type to their on-going deals, and to create documents outside of those deals. In cases where, for example, the structure and content of a particular document depends on the shared 5 data, document-specific data may be generated from the shared data. Further, the various scripts can Instruct the system 1 to elicit information from the user that determines the details of the generated document-specific data, and what information is so elicited can be controlled, for example, by the shared data. In short, this functionality ensures that the rules in drafting scripts (and in some other scripts) that 10 drive the generation of documents are evaluated by using the correct pieces of data, and that those pieces of data have only had to be entered once. [002331 The two key aspects to this facility of the system 1 are, firstly, that drafting scripts are driven by parameters, and, secondly, that there is a mechanism by which 15 from any document-type script, the identifiers of all the shared data containers used by that document-type script can be determined. When a user adds a new document to a deal, the system 1 knows from the corresponding document-type script which types of data container the document needs. Such containers are held in a 'virtual repository' created specifically for the deal. For any type of container needed, the system will find 20 it in the virtual repository if such a container already exists there, or it will add it to the repository if it doesn't yet exist. Meanwhile, the document-type script binds parameters of its declared drafting script to named data items, the names identifying the container and the desired object within the container. In many cases, exactly which of a collection of data Items a user requires a document to employ is under the control of the user via 25 a reference-chooser control or a set-chooser control, where items are picked for a particular document from a deal-wide array of data items. Finally, the case of an ad hoc, stand-alone document is treated simply as one where there is no existing deal data when the document type is activated, so the virtual repository is empty and all the deal-wide data containers have to be created. 30 [00234] Creating a document, then, can be considered to consist of the following steps: 1. When working on a deal, a user chooses a type of document to be generated, and this action activates a corresponding document-type script. (in the stand 35 alone case, the 'deal' being worked on is an 'empty' deal.) That document-type script may specify a web of shared document-type scripts.

62 2. If necessary, the system creates containers of data in a virtual repository for the prevailing deal. 3. The user enters data into containers via question sessions. 4. The user requests a generated document. 5 5. The system locates data objects via the object manager interface to the virtual repository, and sets the values of drafting script parameters to those objects based on the binding specified in the activated document-type script. 6. The system executes the rules of the drafting scripts to produce the generated document. 10 [00235] As mentioned above, the fundamental function of the object manager in the system 1 is to return data objects given an object locator (obloc). Accordingly, authored scripts use these 'oblocs', which are structured identifiers, to express relationships between data objects. 15 [00236] In the following explanation of oblocs, reference is made to the script element 14 above. That script element uses the following three oblocs in the content of the da:setParam elements. 20 1. signAs 2. practicallaw.com/qs/gsess-script2/target 3. shopDetails 25 [002371 These three oblocs are being used to set drafting-script parameters to data items produced by question sessions. In particular, the oblocs 'signAs' and 'shopDetails' are being used to obtain the values of answers obtained from a question session generated by the local question-session script 'qsess script' Identified by the da:local element of the script element 14, and to set certain parameters in the drafting 30 script 'draft scriptt' to those values, In contrast, the second obloc practicallaw.com/qs/qsess script2/target' is being used to obtain the value of an answer in a question session generated by the question-session script 'qsess script2 specified by one of the shared document-type scripts, namely 'doctype2, and to set a parameter to that value. 35 63 [00238] The second obloc referring to the 'target' is prefixed with a 'container id'; in this case the container id identifies the container of responses for the question-session script 'qsseasscript2', 5 [00239] Although not shown by the above three examples, oblocs can use a 'dot' notation in order to reference objects in the object tree (the idea of data objects having a tree structure is described above). For instance, suppose that the shopDetails object has a property 'address'. Suppose also that the type of that property is 'Address', and that a property of 'Address' is postcodee'. In that case, an obloc for referring to the 10 postcode of the address of a shop might be as follows. shopDetails -address .- postcode [00240] This obloc could be used in a document-type script to set a parameter to the 15 corresponding postcode data value, It will of course be appreciated that this dot notation can also be used in oblocs which are prefixed by container ids. So, for instance, the obloc below could be used to refer to the registered name of the target company, where the target company is specified in the shared question-session script given by the container id. 20 practicallaw, com/qs/qsessscripL2/targeb. reqisceredName [00241] A 'dot notation path' is a sequence of one or more property names, and where there's more than one such property name, each such name is separated by a dot ('. 25 Accordingly, oblocs are defined as either a dot notation path (i.e. a 'local' obloc) or a dot notation path prefixed by a container-id (ile. a 'remote' obloc). It will be appreciated that oblocs can be more complex than either of these types, for example they may contain special characters that indicate a relative path from one object to another. Such complex types of oblocs are not described herein, however it is to be appreciated that 30 the present invention extends to such complex obloc types. [00242] As mentioned above, oblocs are interpreted in the system 1 by an 'object manager'. That is, the function of an object manager is to return a data object, given an obloc. An object manager provides a common interface to a number of data containers. 35 [00243] It has already been explained that, at any time, one of the containers accessible by an object manager is the 'local' container, and local oblocs will be 64 interpreted as referring to objects in that container. Other containers made available by the object manager will require a container-id in order to be selected. It has also already been explained that the container in which question-session data is stored can be considered to be the root of an object tree whose immediate children are instances 5 of data types such as Persons, Obligations, etc. An object manager can delegate the resolution of dot notation paths to a response container, and the container will return the object located by the path (if any exists). In general, a container in the context of the system 1 is any software object which will allow this functionality to be performed. That is, In general, a container is any software object which can be considered the root 10 of an object tree whose immediate children are instances of defined data types, and to which an object manager can delegate dot notation path resolution, [00244] The practical consequence of this general definition of a container is that a very wide range of data storage technologies can be made available to the system as 15 containers. The technique employed by the system 1 for making such a technology available is to employ a piece of software called a Container Adapter. From the perspective of an object manager, a Container Adapter implements all the functions that it expects from a container, however the Container Adapter will implement these functions by using the technology which it is making available for use by the system 1. 20 For example, one type of Container Adapter obtains objects from a relational database, thus enabling the system 1 to generate documents which are based on data drawn directly from that database. [00245] Figure 20 is a schematic diagram 200 for illustrating the function of an object 25 manager, and the role of a container adapter. The schematic diagram 200 presents a document-type script 202, a document-type-script interpreter 204, an object manager 206, a first container 208, a second container 210, a third container 212, and a relational database 214. 30 [00246] When a user starts or returns to a deal, the user elects either to generate a new type of document, or to work on an existing document, In either case, the corresponding document-type script 202 is activated, and is interpreted by the document-type-script interpreter 204. Accordingly, an object manager 206 for that user session is created and initialised. Further, the 'da;Iocal' element of the document-type 35 script 202 tells the object manager 206 to set up a container as the 'local' container, in this case the first container 208. Then the rules described above are used to register 65 other containers with the object manager in dependence upon the document-type script 202, in this case the second container 210 and the third container 212. Those other containers thus registered are those specified by the 'da:shared' elements in the document-type script 202. 5 [00247] In the case exemplified by Figure 20, the first container 208 and the second container 210 are question session containers, The first container 208 is available by using local oblocs, and the second container 210 is available by using remote oblocs. The third container 212 is a Container Adapter for the relational database 214, and so 10 the document-type script 202 is able to set drafting script parameters to data drawn from that database. DRAFTING SCRIPTS 15 [00248] As explained above, a drafting script is a parameterised function whose immediate product is an XML document or a part of an XML document. The XML represents document data in a way which is neutral between different rendering styles and media. 20 [00249] The script element 16 below is a first example of part of a drafting script, and represents a paragraph that expresses the value of a data item. That is, the value of the data item bound to the parameter "buyerName" by a corresponding document-type script will appear in the paragraph of the generated XML document. 25 <para> <da:ux>p("buyerName")</da:ex> shall pay all present and future stamp, documentary and other (16) like duties and taxes (if any) to which this agreement may be subject or may give rise. 30 </para> [00250] The script element 17 below is a second example of part of a drafting script. Similarly to the script element 16, this element also contains a data item expression, but in additon it chooses different document content depending on the tested value of 35 the data item. This is effected by the 'da:if' tags. <da:choice> <da:if'p("buyerType").is("person")</da:ift. <da:select>Signed by <da:cx>p("buyerName")</da:ex></da:select> (17) <da:if >p("buiyerflype").is("company")</da-t.if> <da:select>Signed by <da:ex>p("buyerDiretor")</da:ex>for and on behalf of <da: exp("buyerName")</da;ex></da:select> </da:choice> 5 [00251] The system 1 has been designed with complex documents in mind, for example legal documents. Different legal documents often contain similar clauses. Changes in the law or changes in accepted phrasing often require changes to every document which contains a particular kind of clause or variant of that clause. 10 Accordingly, the system 1 has been designed to employ re-usable script modules to build up whole documents. That is, each module is used to generate a particular kind of clause, and a draft document is made up of the result of each unit generating its particular part. 15 [00252] Drafting scripts which create complete documents are called 'document drafting scripts, and those which create parts of documents are 'clause' drafting scripts. A document drafting script delegates to clause drafting scripts to create its parts. In fact, it may even delegate to itsef, thus supporting recursive algorithms. Correspondingly, a clause drafting script may delegate to sub-clause drafting scripts. 20 The generation of a draft document can thus involve a 'delegation graph', with the document script delegating to clause scripts, and the clause scripts delegating to sub clause scripts, and so on to any arbitrary depth. [00253] For a drafting script to delegate to another drafting script, it must provide an 25 identifier of the script and set its parameters. It sets the parameters of the script to which it delegates from the values of its own the parameters. [00254] A document drafting script which creates a complete document - that is, a script at the root of the delegation tree - is referenced directly by a document-type 30 script. The document-type script, as described above, associates drafting scripts with question-session scripts and identifies the applicable default data. The document-type script is also responsible for setting the values of the parameters of the document drafting script that it references. This, accordingly, is the overall mechanism by which data is input into the drafting script delegation tree in order to produce the final output 35 document.

67 100255] By way of example, the script element 16 above could be used in a simple drafting script such as the following drafting script of script element 18. <da:drat1Soripjt xmlns:da="http://practicallaw.m/ple/da"> 5 <daparamDecls <d: r'amrtDecl name="buyerName" ype="oom.practical law,obj. Simple" /> (18) </da:paramDecls> s<daexlp("buyerNaml")</da:ex-sbal pay all present and future stamp, documentary and 10 other like dutit and taxes (if any) to which this agreement may be subject or may give rise, </para> <da:dralScrip't [00256] The 'da:paramDecls' element of the script element 18 contains a number of 15 'da:paramDecl' elements. Each 'da;paramDecl' element declares a parameter to the function defined by the drafting script of the script element 18. In this case, there is a single parameter, called 'buyerName', whose type is 'Simple'. [00257] Elements which pertain to the dynamic, generative aspect of the drafting script 20 are prefixed by 'da' (they are in the 'da' namespace). Elements which may appear in the generated XML draft document (an instance document) have no such prefix. That is, drafting scripts use an XML mark-up that contains a mixture of tags which describe the logical structure of the document, together with tags (prefixed by 'da' ) which provide the rules to determine how the content of such a document depends on 25 transaction data. In contrast, XML draft documents (produced from drafting scripts) are valid against a predetermined QTD which describes only a part of the mark-up for drafting scripts. A document which conforms to this DTD is a document which contains tags to describe its logical structure. These tags can represent, particularly in the case of legal documents,: 30 - The logical representation of the various constituents of a legal document (parties, recitals, operative, execution, schedule, appendices). * Representation the various nested levels of an individual clause * Cross-referencing between different parts of a legal agreement. * Structured representation of defined terms and their definitions 35 a A logical representation of the document coversheet a A logical connection between the agreement parties and document execution 68 [00258] Drafting scripts are identified by a unique resource identifier, In this case, for the purposes of the example, it is assumed that the drafting script of the script element 18 is identified by the resource identifier: 5 practicallaw.com/tp/sample-dscript_1 [00259] Accordingly, other drafting scripts can use the drafting script of the script element 18 by using this a 'da:include' element and the above identifier. This is illustrated in the following script element 19, which may be assumed to be called 10 'sample_dscript 2', <dn:draftScript xmIns:da="lhtp://practicallaw.co/le/da"> cda:pararnDccls> 1 daparaniDeci mnic"buyer" :pc="com.prationllaw.htypes. UKCompany" t> 15 <da:paramDecls> -- clause> <idtle>Csos<ftitIc> (19) <para> Unless othe-wise special, all costs in onncdon with the negotiation, preparation, 20 execution and perfonnance of this document, and any documents referred to in it shall he burne by the party that incurred the costs. /para> cda:include idrf="practicallaw.com/tp/sample dscript 1 "> <ca:with larnnT namc="huyerNamc" >p("buyer.registeredName")</da:widi Panam> 25 </da:incluc> <clause> </da:draftScript> [00260] It is to be noted that the parameter 'buyer' declared in the "including script" 30 (script element 19) is of a "UKCompany" type. However, the parameter 'buyerName' declared in the "included script" (script element 18) is of a Simple type. The 'da:withParam' element of the script element 19 binds the value of the registeredName property of the UKCompany to the buyerName parameter. 35 (00261] The including script ('sample dscript 2') may itself be included in one or more other drafting scripts or it may be specified directly by a document-type script. In the present example, the drafting script 'sampledscript_2' is the top-level document drafting script (albeit a rather unrealistically short one). 40 [002621 If the drafting script 'sample ,dscript_2' was a document drafting script, the document-type script directly referencing it could be the script element 20 below. <da:docunentType xmlns:da="http://practicalliw.com/ple/da"> <da:local idref="practicallaw com/qs/samp~cqscript"> 69 <da:dcfaultData idref"practillaw.com/gssamplequeript defauhs"> (20) C/d:aIocaI> <da:forD ftScript idreF="practicanlaw.com/tp/samlejv dscript 2> <dasctParamn 5 </da:foroDra1vI-ip> c/da:documntType> [00263] In considering the script element 20, the following features should be noted. The 'da:local' element specifies a question-session script via an identifier. That 10 particular question-session script would normally refer to at least a group type (i.e. generate a control) which elicits data for a "UKCompany" domain (data) type. The 'a:defaultData' element specifies a container of data which supplies the defaults for the objects which can be edited via the specified question-session script. The 'da:forDraft$cript' element specifies the sample document script 'sample dscript_2' via 15 its identifier. The 'da:setParam' element sets the value of 'sample..dscript_2's parameter called 'buyer' The content of the 'da:setParam' element is a reference to a data item which, when the document-type script of the script element 20 is activated, will contain the company data elicited by the question-session script (and whose default properties are supplied by the default container). The name 'purchaser in this 20 example is the name of the group (control) generated based on the question-session script and is also here used as the identifier (obloc) of the object for which the group is responsible. For the sake of simplicity, the script element 20 does not include any shared data, 25 [00264] Figure 21 is a schematic flow diagram 210 to illustrate how a user might interact with the system 1. The flow diagram 210 presents interface screens 211, 212 and 213. [00265] In the scenario depicted in Figure 21, the user is first presented with interface 30 screen 211, which comprises a control to allow the user to enter company data. The control of the interface screen 211 displays default data, and the user can replace this data with actual data, thereby producing interface screen 212. The user then proceeds to interface screen 213 by electing to view the document. It is to be ntoed that the entered company name "Trustthorpe Ltd" appears in the generated document 35 as a hypertext link 214. This enables the user to link back from the generated document to the relevant portion of the question session, i.e. to the interface screen 212.

70 [00266] The link 214 accordingly allows the user to modify the data after having seen the document. Indeed, the user could have elected to view the document without having supplied any data, in which case the default data "Company Name" would have appeared in the generated document as the link 214. Clicking on the link in that case 5 would have taken the user to interface screen 211 to allow the user to enter the company details. [00267] As illustrated in Figure 21, users require links to editing controls for any piece of data used in the generation of the document. This includes document-specific and 10 deal-wide data. As well as providing these links, the system 1 also allows users to be made aware of the effects on the generated document that changes to the data will make, even before the changes are actually made. This facility of the system 1 will now be explained in detail. 15 [00268] Many kinds of user (lawyers in particular) prefer to start with a first rough draft of a document and then refine it, In other words such users tend to want to see a version of the document that they are working on at a very early stage in the process, even before they've entered any data. Accordingly, the system 1 is capable of showing a first draft of a document generated using a default set of data. The user may then 20 allow the user to navigate via links, such as link 214 of Figure 21, back to controls which enable him to change that data. The document can then be re-generated and if necessary the data can be re-edited in an iterative view-document/change data/generate-document cycle. 25 [00269] It is desirable for a user to know, when working in this way, just how a change to a piece of data will affect the generated document. For example, it would be unsatisfactory for a user, in the case that a certain clause ought to be present in the generated document, to have to track down the question which pertains to the inclusion of the clause and further to have to work out the answer which will make it appear. 30 [00270] Against this background, the system 1 allows a user to view the rules (or some of the rules) that the system uses to create the document. The rules may be shown alongside or embedded in the rendered generated document. Thus, the user can see exactly what the effects will be of changes to the data that he or she makes. 35 71 [00271] The system 1 allows the generated draft document to be shown in a mode which supplies information about how the draft would appear were the data values different. The author of the drafting script controls what appears in this mode. The system 1 thus allows authors to decide just which rules are shown alongside or 5 embedded in the rendered generated document, since In many cases displaying all of the rules would generate an overwhelmingly complex document. The user can choose to view the generated draft in this mode, or in a 'final version' mode, from which this information is removed, 10 [002721 The draft also contains links to data-edit controls enabling the user to modify the default values and add new information. The links can connect either to edit controls defined in a question session or to data input controls defined in an external application. 15 [00273] The following extract from a generated confidentiality agreement illustrates some of these concepts. 3.2 Before the Buyer discloses any information under this clause, the Buver shall [use his or her [best] OR [reasonable] endeavours to]: 20 (a) inform the Seller of the full circumstances of the disclosure and the information that will he disclosed; [(x) give the Seller a copy of a legal opinion indicating thal disclosure is necessary;] 25 [00274] The hypertext links from 'the Buyer' and 'the Seller' are to questions about which term to use for these roles (for instance, alternatives might be 'Purchaser' and Vendor'). The square brackets are 'optionality links'. The text between the brackets is optional; that is, there are parameters to the drafting script whose values control whether the text is present or absent. The optionality links navigate to questions that 30 supply those values. Some square brackets surround black text and some surround greyed text. The colour of the text indicates whether it is 'present' or 'absent' given the current parameter values. The black optional text is 'present' given the current parameter values, and the grey text is 'absent' given those values. More precisely, for the black optional text, the values of the parameters which control its presence are 35 such that the text will appear in the final version of the generated document. For greyed optional text, the values of its controlling parameters are such that the text will not 72 appear. Accordingly, when the user chooses to view or print the final version of the generated document, the 'absent text is effectively removed. [00275] In the above extract, a greyed 'OR' is inserted between the two options 'best' 5 or 'reasonable' This occurs automatically where two options are alternatives to one another. Options can be nested within other options. For example a version of this document favouring the seller would take out entirely the section 'use his or her endeavours to'. 10 [00276J It is to be appreciated that although this description of the system 1 refers to the values of parameters as driving the presence or absence of text, not all parameters are simple. As explained above, many are instances of complex business types which have named properties, and those properties themselves may be instances of complex business types. For example, the wording produced by a particular drafting script 15 having a parameter that is a company (whose type is "Company") may depend on a property of the company defined within the Company type. For example, the wording may depend on the country of residence of the company secretary, where the company secretary is a sub-property (whose type is Person) of the company, and the country of residence is a sub-property of the secretary. In order to avoid having always to qualify 20 the expression 'value of a parameter' with 'or one of its properties, or properties of its properties...'; the expression should be understood in a broad sense, when a value of a parameter is said to be referenced, or expressed, or tested, it should be understood as meaning a value of any property in its property tree as explained previously. This example is illustrated by the following dot notation for the country of residence of the 25 secretary of the company, which effectively says "access the countryOfResidence property of the Person object that is the 'secretary' property of the company parameter'. company. secretary. countryOfiResidence 30 [00277] The following script element 21 is an example of a drafting script that would produce the above extract from a generated confidentiality agreement. The various devices which it illustrates are described thereafter. 35 <da:drafScript xmins:da-"http://prawto law~com/jplcfda"> <da:parmDvcls> 73 <daparamnDeel name="forceDiscI Erdeavours" tvpe=colm.practicalIuw,btypc.general.StrivcLcvel" ,CdaparamDecl name-"forceDisc]Logalopinii lypc="con.practicallaw.btype.general.Boolean". <da:paranDccl name*"diloser type='"co.practicallawih.obj.Simple"/> <cda:parmDecl nan1="reccive' type"com.practical1aw.ls.obj.Simple'/> 5 f<da:paramDeels> <clause> <para>f3ctrc <da:ex>p("rocciver")</da:ex> discloses any infonnation undwr this clause, da:ex>p("rocciver")C/Iacx> shall (Lo thc extent permitted by law) <da:options> 10 <da;i pi-ov='p("forceoisclEndeavours")>p("forceviscr Endcavouis"),is("best") 1 p(" foroDiscl Eudeavours").is("remonable")</da' r> <da:option> use his or her <da:options> 15 <da:if prov'-'p("forccDiscl~ndeavours")'>p("forceDis1Endcavours").is("bst")/da:if> <da:opdon>best<./da:option> <da:if pror='p("forceDl8IEndcavours")>p("frccDiscEndeavours").is("reasnable")</daifb <da:option>reasonable</daioption> /Vda:optians> 20 cndeavours Lo 4/da:option> <daopions> </pan> 25 <paa>inform <da:cx>p("discloer")</da:ex> or the full circumstances of the disclosure aid the information that will be disc] osed</para> </clause> da:opions> <da;if prov='p("forceDisclLegalCpin ion")'>p("forceDisol LgalOpinion").is("Tue")</da~if 30 <da:optioi> clauseo> <pare>give <da:ex~p("discloser")</da:ex> a copy of a logal opinion indicating that disclosure is necessary</pra> clausesc> 35 </dmoption> /da:options> /clause> <Jda:draflScript> 40 [00278] The 'da:ex' tag is the device used in drafting scripts to express the value of a parameter in the generated document and to create a link to a control by which a user sets or modifies this value. As explained above, a parameter will have been set from a container (using an obloc). A container of answers to a question session is one type of container, but there can be other types. In the general case, any system which is able 45 to resolve dot notation paths is able to act as a container in this sense. [00279] Container Adapters were described above to explain how data could be accessed from an external source such as a database. It is therefore to be appreciated that a Container Adapter should be able to resolve dot notation paths, and that the 50 objects it returns are instances of data types (Persons, Obligations, etc). Further, from the perspective of a drafting script, there is no difference between receiving a parameter which has been obtained from one kind of container rather than from another.

74 [00280] As suggested above, a da:ex tag does not merely express the value of a parameter, it also creates a link to enable a user to modify that data. Therefore, any parameter value must contain information which will enable the creation of such a link, 5 Thus any parameter contains, as well as its value, a piece of data called a 'provenance'. A provenance is a URL (Universal Resource Locator) which will be rendered so as to allow a user to navigate to a control to modify the value of the data. [00281] The 'da:if tag is the device used in drafting scripts to enable the conditional 10 insertion of text. The content of a da:if tag can be an expression from a programming language such as Java which evaluates to true or false, and it will normally be an expression which tests the value of a parameter. By way of example, reference is made to the script element 17 provided above. That script element illustrates a choice of different document content depending on the tested value of a parameter. The script 15 element 17 will accordingly output one form of words if the buyer is a person and another form of words if the buyer is a company. That is, the content of the da:select whose da:if is false will simply not be generated, and it will not appear in any guise in the generated document. 20 [00282] Optionality, i.e. showing the user the effect of other data values, uses da:if tags in a slightly different way. In order to illustrate these differences, the following script element 22 is provided. The script element 22 is an extract of the script element 21 provided above. 25 da::ptions <da:if prov'p("forccDisc]Endeavours'>p("forcenioEndeavours")i("best")<da:ith <da: option>-best</da: option> (22) <da: i prov=("forceDiaolEndeavous")'>p("fomeoDiso Endcavours").is("reason bd ")</da:if <daI:opton-reasonabloc/da:option> 30<da:options [00283] The da:options element is like a da;choice element in that it selects between two alternatives based on the value of a parameter. However the da;options tag signals to the system 1 that both alternatives need to be generated, and both appear in the 35 generated document, except one is marked as 'present' and the other marked as 'absent'. [00284] The format of the generated document is a medium-neutral XML document as discussed above. The step of actually rendering the generated document occurs after 75 this medium-neutral representation has been created. This concept is discussed above with reference to Figure 3A. The difference between the mode of presentation which shows both 'absent' and 'present' text and that which shows just 'present' text - the final version mode - is a difference in rendering. That is, in the final version mode text 5 marked as absent is removed (and in the other mode, that text may be rendered greyed out, as above). 100285] The prove " attribute of the da:if element in the script element 22 associates a provenance with the option for the purpose of generating a link to effect a change to 10 the relevant data object. In both cases, the provenance specified is for the very parameter whose value is being tested in the da:if content, This is typical, but not essential. For instance if the object being tested is a property of an instance of a business type, it can sometimes be a good idea to link back to the control for the complete object, rather than just to the property which is being tested. 15 100286] In the case of generating legal documents, one or more execution clauses are normally required to allow the parties the document to sign it. As previously mentioned, the form of an execution clause in a legal document depends on the kind of document being signed and on the nature of parties which are signing it. For example, 20 different forms are required if a party is a company, or if a director to a company is a company, or if a party is represented by an attorney (and whether the attorney is a company or a real person also makes a difference). [00287] The logic determining the form of an execution clause is intricate and depends 25 on information which is shared between different documents in a deal (for example information about the parties to the document) and also on information which is specific to the document (for example whether the document is being signed as an agreement or a deed). Furthermore, some of the information which is specific to the document depends on information which is shared between documents. For example the 30 question of whether a party is signing by the use of its seal or not only makes sense if the party is a company and not if the party is a real person. [00288] Information which is specific to the document needs to be elicited from the user in the context of the generation of the document. Thus, which information of this 35 sort needs to be elicited from the user, is dependent upon information which is not document-specific.

76 [00289] In view of the complexity of the logic required to produce an execution clause, the system 1 employs a parameterised re-usable module to hold that logic, That module can be an XML script that can be referenced in a drafting script. Accordingly, 5 an. author can in effect reference this relatively complex script when he is writing a new drafting script, i.e. he does not have to write that complex script himself, Accordingly, the drafting script used to generate an execution clause of a document may be an XML script of the re-usable kind described above, 10 [00290] Users of the system 1 generally employ the system to generate initial drafts of documents, and may typically wish to continue to revise and modify those documents, sometimes quite substantially, before they are considered working first drafts. [00291] It is desirable for revisions and modifications to draft documents to be done on 15 the automated manifestation of these documents, within the system. This maintains the ability for the document to respond to changes in data held in the system even as it is further modified by the user in substantial ways. [00292] One way that draft documents generated from executing the drafting scripts 20 (based on the data collected from question sessions) can be modified is by changing the values of the collected data, and regenerating the draft document from the new data. This type of modification has been described already above, and is a manifestation of the feedback route 42 of Figure 3A. This type of modification is however a very restricted class of modification, and does not allow, for example, the 25 free editing of data-independent text within the document. [00293] One way to achieve the flexibility in editing actual text within a draft document is to export it into a word processing format such as MS Word, and then to edit the resulting word processing file, However, this disconnects the draft from (he document 30 automation system, such that a regeneration of the draft document from the system 1 results in an un-amended version of the draft document. [00294] In general, in existing document automation systems, it is impossible to allow users to freely edit the results of a document generation, and then preserve these user 35 modifications along with changes in the data used to generate the document by applying the automation. Users of such existing systems are faced with the Hobson's 77 choice of either losing the automation and data centralisation of those systems, or losing the ability to freely modify the draft document, In contrast, the system 1 has been designed to allow users to amend both data and document content without losing the automation afforded by that system. 5 [00295] The system 1 is operable to generate unique instances of modifiable drafting scripts for each document created in the system, and to allow textual modifications made by users in the created document to be preserved and recreated specifically for that document. 10 [00296] In general, as described above, a document drafting script is the designated root of a delegation graph, which contains clause and sub-clause drafting scripts to any arbitrary degree of depth. The system 1 generates an instance of a drafting script and each sub-drefting script, based on the original authored drafting script. That is, these 15 instance drafting scripts are generated for each node of the delegation graph, forming a unique modifiable instance of that delegation graph which is permanently associated with a particular document. [00297] At the time of their creation, these drafting script instances are identical to the 20 original authored drafting scripts, except that they are further marked-up automatically by the system 1 with unique element id's for each fragment of text or mark-up present therein, and further, references delegating execution to sub-drafting scripts are automatically replaced with references to the newly created unique sub-drafting script instances associated with the particular document. 25 [00298] it has already been explained that the product of a drafting script, when executed, is a representation of a draft document in XML. It has also already been explained that this product is further transformed into a rendition of the document draft in a form suitable for an application running on the user's computer, such as a web 30 browser or a word processor. The final document draft seen by the user is therefore normally at least two distinct transformations removed from the drafting script instance used to generate it. The first transformation is from the drafting script instance to the XML document produced by executing that drafting script (and it's graph of delegations). The second transformation is from that XML document into an output 35 format such as HTML for web-browsers or Microsoft Word format for viewing in the Microsoft Word word-processor.

78 [00299] In the system 1, the unique element id's for each fragment of text and mark-up in the Source drafting script instance are maintained, without change, in analogous elements (such as ranges of text, or paragraphing tags) in the final rendered draft 5 delivered to the user's computer, The system 1 further employs custom automations to the application (e.g. to the word processor, or the web browser) running on the user's computer to cause the application to communicate changes in document content as the user makes them, element by element, based on the unique element id's to the system 1. This is made possible by referencing these changes by the unique, in-variant 10 element id of the element that has been changed as a result of the user's modification. The system 1 is then adapted to make identical changes to the uniquely identified source element in the appropriate drafting script instance, which is in turn associated with the particular document the user is working on. When the document is regenerated by the system by executing the drafting script instances associated with 15 that document, the user's textual modifications are recreated exactly as they were made in the original application (e.g. word-processor or web-browser). [00300] In order to consider the use of element id's further, reference is made to the the drafting script examples provided as script elements 18 ('sample dscript 1') and 19 20 ('sample_dscript _2') above. The second of those drafting scripts is identified by the URI 'practicallaw.com/tp/sampledscript2' and delegates to the first of those drafting scripts by the URI 'practicallaw-com/tp/sample-dscript_1'. [00301] In order to allow a user to create a document using a document-type script 25 that references the drafting script 'sample dscript_2', and to allow the user to benefit from the system of drafting script instances described above, the system I is adapted to create specific amendable drafting script instances with new unique identifiers. Such drafting script instances that could be created by the system 1 in this situation are provided below as script elements 23 and 24. Script element 23 corresponds to script 30 element 19, and script element 24 corresponds to script element 18. pracucallaw.com/tp/sample-dscript 2/tpx/tl <da draflScriptInstance xniis:a="http://prtticallaw.coi/plc/da"> 35 .da:parmDcs> <da:para Dc name="uyer" typc-"com.practicallaw. types. UKCompwiy" /> <.da:parnrnDccis> claue elemid-"a3891" rpid="practicallaw.com/p/sanple dsCriPt2/tpX/tl " <title demikl="a3892" tpd="practicallaw. comtp/sample dscipt_2/tpx/ 1 ">Costs</ite> 79 <para cleicd="3893" tpid="pr-acticallawsoim/tp/sample_dscript_2/p/l" Unless otherwise specified, till costs in connection whli the negotiation, preparation, (23) execution and performance of this document, and any documents referred to in it shall be borne by the party that incurred the costs. 5 </parc> <ds:include elemid="a3894" tpid="practicalluw.com/tp/sample dscript2/px/t" dref="practicallaw.com/t/sanmple dscript I/tpx/s2 > <da:withParam mime="buyerNgmc" >p(" buyer.registeredNarine")</da:withParATn> </da~mclude> 10 </Alause> /da:draftSciptinstance> 15 practicallaw.comtp/eampleciecdptl/tpxt2; <da:drallScriptnstance xmlns:da= "http://practicailaw.con/plc/da"> <da:param Decls> <da:paramDeol name="buyerName" type="con practicallaw. lsObj. Simple" /> (24) </da pararnDels> 20 <parn elcmid="b200 " tpici="practicalluw.conVtp/sarrple dscript I/tpx/s2> <da:cx elemid="b2002" pid="pracdicalia w.om/~tp/samp[e_.dsoriptL/tpx/s2>-p("buiycrName")<daex> shall pay all present and future stamp, documentary and other like duties and taxes (if any) to which this agreement ay be subject or may give rise. 25<Pm <-du:draftScriptlinstancc> [00302] The new drafting script instances of the script elements 23 and 24 are identical to the original drafting scripts of the script elements 19 and 18, respectively, 30 except for the insertion of unique element-id's, e.g. "a3891", for each amendable fragment, and the modification of delegation calls through da:include elements. In addition to the element-id's it will be appreciated that each amendable fragment also comprises a script-instance id, as identified by "tpid" in the scripts elements 23 and 24. These script-instance id's identify the script instance which the amendable fragment is 35 part of. It will be appreciated that the use of both the element-id's and the script instance id's may simplify or speed up the searching process for a particular amendable fragment, and will also reduce the burden on the system 1 to generate element-id's that are unique amongst all script instances. However, it will be appreciated that the script elements 23 and 24 could be employed without the script 40 Instance id's, if the element-id's are unique amongst element id's employed by the system. [003031 The da:include element in the new drafting script instance (script element 23) created from sample dscript2 has been modified to refer to the new drafting script 45 instance (script element 24) created for sample dscript_1.

80 [00304] On the first, and each subsequent regeneration of a draft document for this particular document instance, it is these new drafting script instances that will be executed to generate the draft document from the data supplied as parameters, rather than the original drafting scripts. Further, the draft document content delivered to the 5 user's computer will contain the element-id's which originate in the drafting script instances, although these will be invisible to the user. [00305] Figure 22 is a schematic flow diagram 220 to illustrate how a user might interact with the system 1. The flow diagram 220 presents interface screens 221, 222 10 and 223. [00306] In this scenario depicted in Figure 22, the user is first presented with interface screen 221, which comprises a generated draft document. The user then chooses to edit the generated draft document to the form shown in interface 222, and then saves 15 these changes, thereby producing interface screen 223. [00307] In this example, the user's modifications to the draft document affect two distinct elements in the underlying drafting script instances, specificaly, these are elements a3892 and a3893, and both are contained within the drafting script instance 20 'Practicalaw.com/tp/sampe-dscript2/tpx/tl provided above as script element 23. [00308) When the user clicks the 'Save Changes' button, custom extensions to the editing software used on the user's computer will perform the following operations. These operations assume that the custom extensions to the user's editing software are 25 not part of the system 1, however the system 1 could of course comprise those extensions. 1. Examine the draft document content for changes, and identify that the elements a3892 and a3893 have been modified. 30 2. Construct a message to transmit to the system 1, typically to the system server 2 of the system 1, which specifies each element that has been modified, by providing an element-id and a drafting script instance id for each modified element The message will also include the new (modified) content, or other indications of the amendments made, to be inserted for each modified element. 35 3. Transmit the message to the system 1, which will make the corresponding amendments to the underlying drafting script instances.

81 4. Refresh the view of the document draft by requesting regeneration of the document draft by executing the amended drafting script instances. This step is not strictly necessary, but is useful so that other changes to data parameters that affect data-dependent aspects of the draft document may also be 5 manifested in the draft document. [00309] The drafting scripts of the script elements 23 and 24 would now be amended by the system 1 as shown in the script elements 25 and 26, respectively, below. 10 practicallaw.com/tp/sample-dscript._2/tpx/l1; <da:drafiScriptinstance xrnsnw:da="http://poficallaw.com/plo/da"> <d;paramDecs> <da:puramDecl name="buyer" type="ium~practicallow.btypes.UKCompiany" /> (25) 15 </da:pcramDccls> clausee clcmid "a3891" tpid="practicullaw.con/tp/sairipl dscript_2/tpx/tI " <title elemid="a3892" pic="pridcallaw.coilp/sample dscript_ 2 /tpx/t I">Expensae</title> <para eleid="a3893" tpid="prtcticallaw.crr/ip/sample script 2tpx/tJ "> Unless otherwise specified, all costs in cunneotion with tle negotiation, preparaion. 20 execution and performance of this duoument, and any documents referred to in it shall be borne by the party that incurred the cosis, except as specifically otherwise agreed to in a separate agreement between the parties. /parq> 25 <ducinclude elenid="u3894" tpid"practicallaw.con/xp/sainple dscript2/tpx/tI' idrc1 "practical law. con/tp/samplelsaript l/tpx/s2 "> <da:withParam name="buyrName" >p("buyor.registcredName")</tu; with Param> </darinclude> </clause> 30 </da:draftScipernstance> 35 practicallaw.corn/tp/sample-dscriptLftpx/s2: <dsudraftScriptlrIsianc xmlns:da="http://practicallawcrm/pi/d~a"; <da:paramDcsl> <da:paran Decl name' buyvrNtnmc" type ."corn.practicallaw. lsobj. Simple" " (26) </da:paramnDcls> 40 <pura ccmid="b20Q1" tpid="pacticallw.comntp/samplecdsiptl/rpx/s2> <da:ex elemid="b2002" rpid="pracrticall uwcon/tp/sampledscript_I/tpx/s2>p("buyerNane")<cla:ex> shall pay all present and future stamp, documentary and other like duties und taxes (if any) to which this agreement may be subject or muy give rise. 45 </para> cla:draftScripthistance> [003101 Accordingly, it can be seen that the users amendment to the text portions of the generated draft document have been preserved in the drafting script instances. 50 That is, the content of the elements a3892 and a3893 in the drafting script instance 'practicallaw.com/tp/sampleodscript_2/tpx/tl' has now changed. There are no changes 82 to drafting script instance 'practIcaflaw.com/tp/sample-dscript_1/tpx/s2' as there were no modifications to any fragments that originated in that script. This functionality is a manifestation of the feedback path 44 of Figure 3A. 5 [003111 it will be appreciated that amendments to portions of such a generated draft document may require not only amendments to textual content or other such content in the corresponding drafting script instance(s), but may also require amendments to logic or other rules expressed therein. For example, if a user deletes a paragraph from such a generated draft document, the drafting script instance concerned could be amended 10 by deleting the logic, as well as the textual content, corresponding to that paragraph from that drafting script instance. If, however, a user adds a new paragraph to such a generated draft document, the drafting script instance could be amended by adding the necessary logic, rule, or markup element for a new paragraph, as well as the new textual content, to that drafting script instance. Accordingly, it will be appreciated that 15 embodiments of the present invention may amend both logic/rules and document content expressed within a drafting script instance. [00312] As explained above, these modifications to the drafting script instances will only affect regenerations of this particular document instance. No other documents 20 created from the same document type will be affected by these changes, and nor will other existing document instances that were previously created from this document type. It will be appreciated that the element id's could be assigned to any level of detail within a drafting script, for example on a per-word or per-letter basis. 25 (00313] It will be appreciated that users generally work on documents for a deal over a period of time that could be many months long. While users work on a deal over many months, it is important that scripts that are used for those documents continue to function correctly. However, at the same time, an author (for example an operator of the system 1) may want to update, edit or publish new scripts to the system. 30 [00314] The system I has accordingly been adapted to allow updates to scripts, while at the same time ensuring that existing user documents and deals remain unaffected. This is achieved by partitioning authored scripts into versioned containers that can be run simultaneously under one instance of the system 1. Documents created by users 35 under a particular versioned container, can remain locked to this container for their lifetime regardless of subsequent releases of new editions of the scripts. Such new 83 editions are released to new versioned containers, In this way, the dependencies of user-created documents on scripts can be locked to a particular version, such that those documents remain undisturbed by updates for the lifetime of those documents, 5 [00315] It will also be appreciated that as more and more users create documents using the system 1, the same authored resources (scripts etc.) -will be usod more and more frequently. The process of reading authored resources from their underlying persistent storage and then parsing them into in-memory objects is computationally intensive. It is therefore important to maintain an in-memory cache of commonly used 10 resources, in order to provide responsiveness and good performance under conditions of high load A problem, however, is that an in-memory cache requires allocation of large amounts of memory for storage. It is important to be able to control the capacity of the cache in such a way that its memory use is controlled. With resources that can be highly heterogeneous in size (ranging from a few bytes to several hundred 15 kilobytes) this is difficult to achieve by a simple number cap on the items in the cache. [00316] The system 1 accordingly allows complex in-memory resource objects to apply an estimated size algorithm that determines a size bucket for that resource to be cached in. The cache maintains several buckets of different size category resources, 20 and assigns resources to buckets based on this algorithm. This allows the cache to be maintained within tolerable limits of a certain level of memory use measured in bytes, without losing the ability to cache many smaller items while restricting larger items. It also allows the cache to provide good performance and scalability, as the expensive operations to get actual exact sizes for complex in-memory objects are not required. 25 100317] It will also be appreciated that the system 1 may be used to produce documents for a variety of different organisations, for example for a variety of different law firms, 30 [00318] Most organisations, for example law firms, expect their documents to be in Microsoft Word format, and each generally have a particular preference about the styling of those Word documents. Styling includes minor rendering matters such as fonts and sizes and also more substantial properties such as the wording of some clauses, forms of punctuation, case and layout of titles and headings, and the location 35 of certain clauses in the document. It is known that the process of rendering a Word document uses XSLT style-sheets. Accordingly, the system 1 holds the rules which 84 determine these properties in a configuration style-sheet in script form, such that a number of different organisation's styles can be managed and maintained by managing and maintaining these configuration scripts, It will be appreciated that differences in rendering requirements from one organisation to another are not 5 limited to Microsoft Word documents, and accordingly that the system 1 is adapted to render other types of output documents differently depending on the organisation concerned. Embodiments of the present invention may be implemented in hardware, or as software modules running on one or more processors, or on a combination 10 thereof. That is, those skilled in the art will appreciate that a microprocessor or digital signal processor (DSP) may be used in practice to implement some or all of the functionality of a server (or other communication equipment) embodying the present invention. The invention may also be embodied as one or more device or apparatus programs (e.g. computer programs and computer program 15 products) for carrying out part or all of any of the methods described herein. Such programs embodying the present invention may be stored on computer-readable media, or could, for example, be in the form of one or more signals. Such signals may be data signals downloadable from an Internet website, or provided on a carrier signal, or in any other form. 20 The present invention is applicable to different types of distributed communication network and does not necessarily need to be implemented over the Internet 4. For example, the present invention may be implemented within a private network such as an intranet, It will be appreciated that, although the embodiments described above 25 have been implemented in software, the present invention may be implemented in hardware. In various aspects the invention may be described by the following statements.

85 1. An electronic-document generation system comprising: (a) a generation unit operable to employ a content source comprising document content and a logic source comprising logic to generate a target document by evaluating said logic in dependence upon data; 5 (b) a user interface operable to cause the target document or another electronic document generated therefrom to be displayed to a user, said user interface being further operable to permit the user to make an amendment to the displayed document; and (c) a source-amending unit operable, when such an amendment other 10 than a change to said data is made to the displayed document, to effect an equivalent amendment to a corresponding portion of the content source and/or the logic source. 2. The electronic-document generation system according to statement 1, wherein said displayed document as amended by the user is a current displayed 15 document, and wherein said equivalent amendment is such that a future such displayed document produced from the amended content and/or logic source would be substantially identical to said current displayed document. 3. The electronic-document generation system according to statement 1 or 2, wherein: 20 said content source and/or said logic source comprise at least one portion identified by a portion identifier, the or each said portion being responsible for the generation of a corresponding portion of said target document; the generation unit is operable, for the or each said portion of the target document, to include the corresponding portion identifier or a portion identifier 25 derived therefrom in said target document; the user interface is operable to; permit the user to make an amendment other than a change to said data to a portion of the displayed document corresponding to the or one of the portions of the target document; and 86 communicate to said source-amending unit the portion identifier included in the target document that corresponds to the amended portion of the displayed document, or a portion identifier derived therefrom, and information about the amendment made; and 5 the source-amending unit is operable to employ the communicated portion identifier and the communicated information to effect an equivalent amendment to the portion of the content source and/or the logic source corresponding to the communicated portion Identifier. 4. The electronic-document generation system according to statement 3, 10 wherein the or each portion identifier is unique amongst any other such identifiers within said sources. 5. The electronic-document generation system according to statement 3 or 4, wherein said sources are expressed in a markup language, and wherein the or each portion identifier is an element identifier identifying an element of the source 15 concerned. 6. The electronic-document generation system according to any preceding statement, wherein: said sources are associated with a source identifier distinguishing them from other such sources employable by the generation unit; 20 the generation unit is operable to include the source identifier, or an identifier derived therefrom, in said target document; the user interface is operable, following such an amendment, to communicate to said source-amending unit the source identifier included in the target document; and 25 the source-amending unit is operable to employ the communicated source identifier to effect an equivalent amendment to the content source and/or the logic source corresponding to the communicated source identifier.

87 7. The electronic-document generation system according to any preceding statement, wherein said logic source and said content source are included within a drafting script. 8. The electronic-document generation system according to statement 7, 5 wherein said drafting script is defined in a markup language, 9. The electronic-document generation system according to statement 8, wherein said markup language is XML. 10. A customising unit for use by a user interface to customise that interface for use with an electronic-document generation system, the user interface being 10 operable to display to a user a document comprising at least one portion identifier corresponding to a portion of that document and being further operable to permit the user to make an amendment to the displayed document, the customising unit comprising an obtaining unit which, following such an amendment to said portion of the displayed document, obtains the portion identifier and information about 15 said amendment from the user interface for use by the electronic-document generation system. 11. The customising unit according to statement 10, further comprising a communicating unit which communicates the obtained portion identifier and said information to said electronic-docurnent generation system. 20 12. A user interface for use with an electronic-document generation system, the user interface comprising: a display unit which displays to a user a document comprising at least one portion identifier corresponding to a portion of that document; an amendment unit which permits the user to make an amendment to the 25 displayed document; and an obtaining unit which, following such an amendment to said portion of the displayed document, obtains the portion identifier and information about said amendment for use by the electronic-document generation system.

68 13. The user interface according to statement 12, further comprising a communicating unit which communicates the obtained portion identifier and said information to said electronic-document generation system. 14. A source-amending unit for use with an electronic-document generation 5 system, the system being operable to employ a content source comprising document content and a logic source comprising logic to generate a target document by evaluating said logic in dependence upon data, and being further operable to cause the target document or another electronic document generated therefrom to be displayed to a user, and being further operable to permit the user 10 to make an amendment to the displayed document, the source-amending unit comprising an amending unit which, when such an amendment other than a change to said data is made to the displayed document, effects an equivalent amendment to a corresponding portion of the content source and/or the logic source. 15 15. An electronic document expressed.in a markup language comprising a plurality of elements, each element of the plurality of elements comprising an element identifier distinct from all element identifiers of that document. 16. The electronic document according to statement 15, wherein said markup language is XML. 20 17. An electronic-document generation system comprising: (a) a generation unit operable to employ a drafting script to generate a target document by evaluating logic expressed within said drafting script in dependence upon data stored in a data source; (b) a user interface operable to cause the target document or another 25 electronic document generated therefrom to be displayed to a user, said user interface being further operable to permit the user to make an amendment to the displayed document; and (c) a drafting-script amending unit operable, when such an amendment other than a change to said data is made to the displayed document, to effect an 30 equivalent amendment to a corresponding portion of the drafting script.

89 18. A computer-Implemented method for use in an electronic-document generation system, the method comprising: (a) employing a content source comprising document content and a logic source comprising logic to generate a target document by evaluating said 5 logic in dependence upon data; (b) displaying the target document, or another electronic document generated therefrom, to a user; (c) permitting the user to make an amendment to the displayed document; and 10 (d) when such an amendment other than a change to said data is made to the displayed document, effecting an equivalent amendment to a corresponding portion of the content source and/or the logic source. 19. A computer-implemented method for generating a target document, the method comprising: 15 accessing a drafting script comprising document content and logic for generation of said target document, said drafting script comprising at least one portion identified by a portion identifier, the or each said portion being responsible for the generation of a corresponding portion of said target document; employing said drafting script to generate said target document by 20 evaluating said logic in dependence upon data; and including in each said portion of the target document the portion identifier of the corresponding portion of the drafting script, or a portion Identifier generated therefrom. 20. A target document generated by a computer-implemented method of: 25 accessing a drafting script comprising document content and logic for generation of said target document, said drafting script comprising at least one portion identified by a portion identifier, the or each said portion being responsible for the generation of a corresponding portion of said target document; employing said drafting script to generate said target document by 30 evaluating said logic in dependence upon data; and 90 including in each said portion of the target document the portion identifier of the corresponding portion of the drafting script, or a portion identifier generated therefrom. 21. A computer-implemented method for customising a user interface of an 5 electronic-document generation system, the user interface being operable to display to a user a document comprising at feast one portion identifier corresponding to a portion of that document and being further operable to permit the user to make an amendment to the displayed document, the method comprising: 10 following such an amendment to said portion of the displayed document, obtaining the portion identifier and information about said amendment for use by the electronic-document generation system. 22. A computer-implemented user interface method for use with an electronic document generation system, the method comprising: 15 displaying to a user a document comprising at least one portion identifier corresponding to a portion of that document; permitting the user to make an amendment to the displayed document; and following such an amendment to said portion of the displayed document, 20 obtaining the portion identifier and information about said amendment for use by the electronic-document generation system. 23. A computer-implemented method for use by an electronic-document generation system, the system being operable to employ a content source comprising document content and a logic source comprising logic to generate a 25 target document by evaluating said logic in dependence upon data, and being further operable to cause the target document or another electronic document generated therefrom to be displayed to a user, and being further operable to permit the user to make an amendment to the displayed document, the method comprising: 91 when such an amendment other than a change to said data is made to the displayed document, effecting an equivalent amendment to a corresponding portion of the content source and/or the logic source. 24. A computer-implemented method for use in an electronic-document 5 generation system, the method comprising: (a) employing a drafting script to generate a target document by evaluating logic expressed within said drafting script in dependence upon data stored in a data source; (b) displaying to a user the target document or another electronic 10 document generated therefrom; (c) permitting the user to make an amendment to the displayed document; and (d) when such an amendment other than a change to said data is made to the displayed document, effecting an equivalent amendment to a 15 corresponding portion of the drafting script. 25. A computer-readable storage medium storing a computer program which, when executed on a computer of an electronic-document generation system, causes the system to: (a) employ a content source comprising document content and a logic 20 source comprising logic to generate a target document by evaluating said logic in dependence upon data; (b) display the target document, or another electronic document generated therefrom, to a user; (c) permit the user to make an amendment to the displayed document; 25 and (d) when such an amendment other than a change to said data is made to the displayed document, effect an equivalent amendment to a corresponding portion of the content source and/or the logic source.

92 26. A computer-readable storage medium storing a computer program for generating a target document which, when executed on a computer of an electronic-document generation system, causes the system to: access a drafting script comprising document content and logic for 5 generation of said target document, said drafting script comprising at least one portion identified by a portion identifier, the or each said portion being responsible for the generation of a corresponding portion of said target document; employ said drafting script to generate said target document by evaluating said logic in dependence upon data; and 10 include in each said portion of the target document the portion identifier of the corresponding portion of the drafting script, or a portion identifier generated therefrom. 27. A computer-readable storage medium storing a computer program for customising a user interface of an electronic-document generation system, the 15 user interface being operable to display to a user a document comprising at least one portion identifier corresponding to a portion of that document and being further operable to permit the user to make an amendment to the displayed document, the computer program, when executed on a computer of the user interface, causing the user interface to: 20 following such an amendment to said portion of the displayed document, obtain the portion identifier and information about said amendment for use by the electronic-document generation system. 28. A computer-readable storage medium storing a computer program which, when executed on a computer of a user interface, causes the user interface to: 25 display to a user a document comprising at least one portion identifier corresponding to a portion of that document; permit the user to make an amendment to the displayed document; and following such an amendment to said portion of the displayed document, obtain the portion identifier and information about said amendment for use by the 30 electronic-document generation system.

93 29. A computer-readable storage medium storing a computer program for use by an electronic-document generation system, the system being operable to employ a content source comprising document content and a logic source comprising logic to generate a target document by evaluating said logic in 5 dependence upon data, and being further operable to cause the target document or another electronic document generated therefrom to be displayed to a user, and being further operable to permit the user to make an amendment to the displayed document, the computer program, when executed on a computer of the system, causing the system to: 10 when such an amendment other than a change to said data is made to the displayed document, effect an equivalent amendment to a corresponding portion of the content source andlor the logic source. 30. A computer-readable storage medium storing a computer program which, when executed on a computer of an electronic-document generation system, 15 causes the system to: (a) employ a drafting script to generate a target document by evaluating logic expressed within said drafting script in dependence upon data stored in a data source; (b) display to a user the target document or another electronic 20 document generated therefrom; (c) permit the user to make an amendment to the displayed document; and (d) when such an amendment other than a change to said data is made to the displayed document, effect an equivalent amendment to a corresponding 25 portion of the drafting script. 31. An electronic-document generation system for generating a target document, the system comprising: an interpreter which, during generation of said target document, interprets at least one instruction of a predetermined type, the or each said instruction 30 referring to data and identifying a content item for use in generating said target document; 94 a first includer which, for the or each said instruction, includes the identified content item or content derived therefrom in a portion of said target document; an assigner which assigns a first status or a second status different from said first status to the or each said portion of the target document in dependence 5 upon said data; and a second include which, for each said portion of the target document, includes additional information in said target document indicative of whether the portion concerned has been assigned said first status or said second status. 32. The electronic-document generation system according to statement 31, 10 wherein the or each said instruction is defined in a markup language. 33. The electronic-document generation system according to statement 31 or 32, wherein the or each said instruction is defined in XML. 34. The electronic-document generation system according to any of statements 31 to 33, wherein said additional information comprises a colour or 15 another symbol. 35. The electronic-document generation system according to any of statements 31 to 34, further comprising; a user interface operable to display said target document, or a document generated therefrom, in a first mode in which any such portion having said 20 second status is included in the displayed document, or in a second mode in which any such portion having said second status is excluded from the displayed document. 36. The electronic-document generation system according to statement 35, wherein said user interface is operable, in said first mode, to include any such 25 additional information in the displayed document and, in said second mode, to exclude any such additional information from the displayed document 37. The electronic-document generation system according to any of statements 31 to 36, further comprising a tester operable, for the or each said 95 instruction, to test the data concerned against a condition defined by logic, wherein said assigner is operable, for the or each said instruction, to assign said first status to the corresponding portion if the data concerned satisfies the condition concerned, and to assign said second status to the corresponding 5 portion if the data concerned does not satisfy the condition concerned. 38. The electronic-document generation system according to statement 37, wherein the Jogic for the or each instruction is defined in its respective instruction. 39. The electronic-document generation system according to any of statements 31 to 38, wherein said interpreter is operable, during generation of 10 said target document, to interpret a group of at least two said instructions, and wherein the system further comprises: a tester operable, for each said instruction of the group in turn, to test the data concerned against a condition defined by logic, wherein said assigner is operable to assign said first status to the portion corresponding to the instruction 15 whose data first satisfies its condition, and to assign said second status to the or each other said portion. 40. The electronic-document generation system according to statement 39, wherein the logic for each said instruction is defined in its respective instruction. 41. An electronic-document generation system for generating a target 20 document, the system comprising: an interpreter which, during generation of said target document, interprets at least one instruction of a first type and at least one instruction of a second type, each said instruction referring to data and identifying a content item for use in generating said target document; 25 a first includer which, for the or each said instruction of the first type, includes the identified content item or content derived therefrom in a corresponding portion of said target document, and which, for the or each said instruction of the second type, includes the identified content item or content derived therefrom in a corresponding portion of said target document or does not 96 include any such content in the target document in dependence upon the data concerned; an assigner which, for the or each said portion corresponding to one of said instructions of the first type, assigns a first status or a second status different 5 from said first status to that portion in dependence upon said data, and which, for any portion corresponding to one of said instructions of the second type, assigns said first status to that portion; and a second includer which, for the or each said portion corresponding to one of said instructions of the first type, includes additional information in said target 10 document identifying that portion as having said first status or said second status, but which, for any portion corresponding to one of said instructions of the second type, does not include such additional information in said target document. 42. The electronic-document generation system according to statement 41, wherein each said instruction is defined in a markup language. 15 43. The electronic-document generation system according to statement 41 or 42, wherein each said instruction is defined in XML. 44. The electronic-document generation system according to any of statements 41 to 43, wherein said additional information comprises a colour or another symbol. 20 45. The electronic-document generation system according to any of statements 41 to 44, further comprising: a user interface operable to display said target document, or a document generated therefrom, in a first mode in which any such portion having said second status is included in the displayed document, or in a second mode in 25 which any such portion having said second status is excluded from the displayed document. 46. The electronic-document generation system according to statement 45, wherein said user interface is operable, in said first mode, to include any such 97 additional information in the displayed document and, in said second mode, to exclude any such additional information from the displayed document. 47. An electronic-document generation system for generating a target document, the system comprising: 5 an interpreter which interprets an instruction of a predetermined type, said instruction referring to working data and identifying a content item for use in generating said target document; a first include which, in dependence upon said data, either includes or does not include said content item or content derived therefrom in said target 10 document; and a second includer which includes additional information in said target document, said additional information being indicative of how a change of said working data to alternative working data would affect the content and/or structure of the target document, 15 48. The electronic-document generation system according to statement 47, wherein said instruction is defined in a markup language. 49. The electronic-document generation system according to statement 47 or 48, wherein said instruction is defined in XML. 50. The electronic-document generation system according to any of 20 statements 47 to 49, wherein said first includer is operable to only include said content item or said content derived therefrom if said working data satisfies a condition defined by logic. 51. The electronic-document generation system according to statement 50, wherein said logic is defined in said instruction. 25 52. The electronic-document generation system according to any of statements 47 to 51, further comprising: 98 a third includer operable to include a link in said target document, said link being operable to access a data-changing device for use in changing said working data to said alternative working data. 53. The electronic-document generation system according to any of 5 statements 47 to 52, wherein said data comprises a composite data item being an instance of a composite data type. 54. The electronic-document generation system according to statement 53, further comprising: a data-accessing unit operable to employ a predetermined definition of 10 said composite data type to access said composite data item for use by at least one of said interpreter and said includers. 55. A computer-implemented method for generating a target document, the method comprising: interpreting at least one instruction of a predetermined type, the or each 15 said instruction referring to data and identifying a content item for use in generating said target document; for the or each said instruction, including the identified content item or content derived therefrom in a portion of said target document; assigning a first status or a second status different from said first status to 20 the or each said portion of the target document in dependence upon said data; and for each said portion of the target document, including additional information in said target document indicative of whether the portion concerned has been assigned said first status or said second status. 25 56. A computer-implemented method for generating a target document, the method comprising: interpreting at least one instruction of a first type and at least one instruction of a second type, each said instruction referring to data and identifying a content item for use in generating said target document; 99 for the or each said instruction of the first type, including the identified content item or content derived therefrom in a corresponding portion of said target document; for the or each said instruction of the second type, including the identified 5 content item or content derived therefrom in a corresponding portion of said target document or not including any such content in the target document in dependence upon the data concerned; for the or each said portion corresponding to one of said instructions of the first type, assigning a first status or a second status different from said first status 10 to that portion in dependence upon said data; for any portion corresponding to one of said instructions of the second type, assigning said first status to that portion; and for the or each said portion corresponding to one of said instructions of the first type, including additional information in said target document identifying that 15 portion as having said first status or said second status, but, for any portion corresponding to one of said instructions of the second type, not including such additional information in said target document. 57. A computer-implemented method for generating a target document, the method comprising: 20 interpreting an instruction of a predetermined type, said instruction referring to working data and identifying a content item for use in generating said target document; in dependence upon said data, either including or not including said content item or content derived therefrom in said target document; and 25 including additional information in said target document, said additional information being indicative of how a change of said working data to alternative working data would affect the content and/or structure of the target document. 58. A computer-readable storage medium storing a computer program which, when executed on a computer of an electronic-document generation system, 30 causes the system to: 100 interpret at least one instruction of a predetermined type, the or each said instruction referring to data and identifying a content item for use in generating a target document; for the or each said instruction, include the identified content item or 5 content derived therefrom in a portion of said target document; assign a first status or a second status different from said first status to the or each said portion of the target document in dependence upon said data; and for each said portion of the target document, include additional information in said target document indicative of whether the portion concerned has been 10 assigned said first status or said second status. 59. A computer-readable storage medium storing a computer program which, when executed on a computer of an electronic-document generation system, causes the system to: interpret at least one instruction of a first type and at least one instruction 15 of a second type, each said instruction referring to data and identifying a content item for use in generating a target document; for the or each said instruction of the first type, include the identified content item or content derived therefrom in a corresponding portion of said target document; 20 for the or each said instruction of the second type, include the identified content item or content derived therefrom in a corresponding portion of said target document or not include any such content in the target document in dependence upon the data concerned; for the or each said portion corresponding to one of said instructions of the 25 first type, assign a first status or a second status different from said first status to that portion in dependence upon said data; for any portion corresponding to one of said instructions of the second type, assign said first status to that portion; and for the or each said portion corresponding to one of said instructions of the 30 first type, include additional information in said target document identifying that portion as having said first status or said second status, but, for any portion 101 corresponding to one of said instructions of the second type, not include such additional information in said target document. 60. A computer-readable storage medium storing a computer program which, when executed on a computer of an electronic-document generation system, 5 causes the system to: interpret an Instruction of a predetermined type, said instruction referring to working data and identifying a content item for use in generating a target document; in dependence upon said data, either include or not include said content 10 item or content derived therefrom in said target document; and include additional information in said target document, said additional information being indicative of how a change of said working data to alternative working data would affect the content and/or structure of the target document. 61. An electronic-document generation system operable to generate a target 15 document by executing a program and at least one subroutine in dependence upon data, wherein the content and/or structure of said target document is dependent upon said data. 62. The electronic-document generation system according to statement 61, wherein said program and said subroutine(s) are each defined in a markup 20 language. 63. The electronic-document generation system according to any of statements 61 to 62, wherein said program and said subroutine(s) are each defined in XML. 64. The electronic-document generation system according to any of 25 statements 61 to 63, wherein said program and said subroutine(s) are each defined in a drafting script accessible by the system. 65. The electronic-document generation system according to any of statements 61 to 64, wherein the or at least one of the subroutines is said 102 program, such that said program is executed at least twice during such generation. 66. The electronic-document generation system according to any of statements 61 to 65, wherein: 5 at least one of said program and said at least one subroutine refers to document content for inclusion in said target document during such generation; and the system is operable to include said document content in the target document in dependence upon said data during said generation. 10 67. The electronic-document generation system according to any of statements 61 to 66, wherein: at least one of said program and said subroutine(s) refers to a rule for evaluation based on said data during such generation, said rule specifying how the content and/or structure of at least a part of said target document should 15 depend upon said data; and the system is operable to evaluate said rule during said generation and to generate said part of the target document in dependence upon a result of said evaluation. 68. The electronic-document generation system according to any of 20 statements 61 to 67, wherein said program is a function declaring at least one parameter for passing said data thereto. 69. The electronic-document generation system according to any of statements 61 to 67, wherein: said program is a function declaring at least one parameter; and 25 the system is operable, during such generation, to: set the or each parameter of said program to a value of at least part of said data based upon predetermined parameter-setting information; and execute said program in dependence upon the or each set parameter.

103 70. The electronic-document generation system according to statement 69, wherein said predetermined parameter-setting information is held in a setting script accessible by the system. 71. The electronic-document generation system according to statement 70, 5 wherein said setting script is defined in a markup-language. 72. The electronic-document generation system according to statement 70 or 71, wherein said setting script is defined in XML. 73. The electronic-document generation system according to any of statements 61 to 72, wherein the or each said subroutine is a function declaring 10 at least one parameter for passing some or all of said data thereto. 74. The electronic-document generation system according to any of statements 61 to 72, wherein: the or each said subroutine is a function declaring at least one parameter; said program and said subroutine(s) are configured such that the or each 15 said subroutine is designated by at least one calling instruction defined in said program or in the or one of the subroutines; each said calling instruction comprises parameter-setting information for setting the or each parameter of the designated subroutine to a value, or part of a value, referred to within the program or subroutine defining that calling instruction; 20 and the system is operable, during such generation and for the or each said subroutine, to: set the or each parameter of the subroutine concerned in dependence upon the parameter-setting information of the calling instruction designating that 25 subroutine; and execute the subroutine concerned in dependence upon the or each set parameter.

104 75. The electronic-document generation system according to statement 74, wherein at least one said value referred to within the program or within one of said subroutines is referred to by referring to a declared parameter. 76. The electronic-document generation system according- to any of 5 statements 61 to 75, wherein said program and said subroutine(s) are configured such that, during said generation, at least one said subroutine is executed at least twice, and such that the content and/or structure of parts of said target document generated by respective executions of that subroutine differ from one another. 77. The electronic-document generation system according to any of 10 statements 61 to 76, wherein: at least one of said program and said subroutine(s) expresses a recursive call instruction designating that program or subroutine and a recursion terminating condition; and the system is operable, during such generation, to execute that program or 15 subroutine recursively until said recursion-terminating condition is satisfied. 78. The electronic-document generation system according to any of statements 61 to 77, wherein such generation comprises the execution of said program and at least two said subroutines, and wherein at least one of said subroutines is configured to call at least another one of said subroutines. 20 79. The electronic-document generation system according to any of statements 61 to 78, wherein the system is operable to execute each said subroutine while suspending execution of the preceding program or subroutine in a nested fashion. 80. The electronic-document generation system according to any of 25 statements 61 to 79, wherein: said data comprises at least one composite data item, the or each composite data item being an instance of a respective composite data type; said program comprises a function declaring a typed parameter for passing a value thereto; 105 the system is operable, during such generation, to: set the typed parameter to a value of the or one of the composite data items of the same type, or to a value of a component part of the or one of said composite data items of the same type, in dependence upon parameter-setting 5 information; and execute said program in dependence upon the set parameter. 81. The electronic-document generation system according to any of statements 61 to 80, wherein said target document is generated in a markup language. 10 82. The electronic-document generation system according to any of statements 61 to 81, wherein said target document is generated in XML. 83. The electronic-document generation system according to any of statements 61 to 82, wherein said target document is in a format suitable for displaying with a word-processing application. 15 84. The electronic-document generation system according to any of statements 61 to 83, wherein said target document Is in any one of an RTF, an HTML, a PDF, and a Microsoft-Word format. 85. The electronic-document generation system according to any of statements 61 to 84, wherein said target document is a formatted text document. 20 86. A computer-implemented method for generating a target document, the method comprising generating the target document by executing a program and at least one subroutine in dependence upon data, wherein the content and/or structure of said target document is dependent upon said data. 87. A computer-readable storage medium storing a computer program for 25 generating a target document which, when executed on a computer of an electronic-document generation system, causes the system to generate the target document by executing a program and at least one subroutine in dependence 106 upon data, wherein the content and/or structure of said target document is dependent upon said data. 88. An electronic-document generation system comprising: a data-accessing unit which employs a predetermined definition of a 5 composite data type to access a composite data item being an instance of said composite data type from a data source; and a generation unit which employs a drafting script written in a markup language to generate a target document by evaluating logic in dependence upon said accessed composite data item. 10 89. The electronic-document generation system according to statement 88, wherein: said predetermined definition comprises an expression definition for use in expressing said data item in said target document; said logic specifies that said data item should be expressed in said target 15 document; and said generation unit is operable to employ said expression definition during generation of said target document to express said data item in the target document. 90. A computer-implemented method for generating a target document, the 20 method comprising: employing a predetermined definition of a composite data type to access a composite data item being an instance of said composite data type from a data source; and employing a drafting script written in a markup language to generate the 25 target document by evaluating logic in dependence upon said accessed composite data item. 91. A computer-readable storage medium storing a computer program which, when executed on a computer of an electronic-document generation system, causes the system to: 107 employ a predetermined definition of a composite data type to access a composite data item being an instance of said composite data type from a data source; and employ a drafting script written in a markup language to generate a target 5 document by evaluating logic in dependence upon said accessed composite data item. 92. An electronic-document generation system, comprising: (a) a configuration unit which accesses a predetermined document-specific script for generating a target document and which, based on information 10 contained within the predetermined document-specific script,: (i) identifies a default-data container comprising default data for said target script; (ii) generates a working-data container and populates that container with said default data; 15 (iii) identifies a data-obtaining unit operable to obtain working data for said target document from a data source other than said default-data container, and stores the obtained working data in the working-data container; (iv) identifies a drafting script comprising document content and 20 logic for generation of said target document, said drafting script declaring parameters for applying data to said drafting script; and (v) binds parameters of said drafting script to data items stored in said working-data container; and (b) a generation unit which employs said drafting script to generate said 25 target document by applying data stored in said working-data container to said drafting script based on said binding and by evaluating said logic in dependence upon said applied data. 93. The electronic-document generation system according to statement 92, wherein said data comprises at least one composite data item, the or each said 30 composite data item being an instance of a respective composite data type.

108 94. A computer-implemented method for generating a target document, the method comprising: (a) accessing a predetermined document-specific script for generating the target document and, based on information contained within the predetermined 5 document-specific script,: (i) identifying a default-data container comprising default data for said target document; (ii) generating a working-data container and populating that container with said default data; 10 (iii) identifying a data-obtaining unit operable to obtain working data for said target document from a data source other than said default-data container, and storing the obtained working data in the working-data container; (iv) identifying a drafting script comprising document content and 15 logic for generation of said target document, said drafting script declaring parameters for applying data to said drafting script; and (v) binding parameters of said drafting script to data items stored in said working-data container; and (b) employing said drafting script to generate said target document by 20 applying data stored In said working-data container to said drafting script based on said binding and by evaluating said logic in dependence upon said applied data. 95. A computer-readable storage medium storing a computer program which, when executed on a computer of an electronic-document generation system, 25 causes the system to: (a) access a predetermined document-specific script for generating a target document and, based on information contained within the predetermined document-specific script,: (i) identify a default-data container comprising default data for said 30 target document; (ii) generate a working-data container and populate that container with said default data; 109 (iii) identify a data-obtaining unit operable to obtain working data for said target document from a data source other than said default-data container, and store the obtained working data in the working-data container; 5 (iv) identify a drafting script comprising document content and logic for generation of said target document, said drafting script declaring parameters for applying data to said drafting script; and (v) bind parameters of said drafting script to data items stored in said working-data container; and 10 (b) employ said drafting script to generate said target document by applying data stored in said working-data container to said drafting script based on said binding and by evaluating said logic in dependence upon said applied data. 15

Claims (32)

1. An electronic-document generation system for generating a target document, the system including: 5 an interpreter which, during generation of said target document, interprets at least one instruction of a predetermined type, the or each said instruction referring to data and identifying a content item for use in generating said target document; a first includer which, for the or each said instruction, includes the identified content item or content derived therefrom in a portion of said target document even 10 when a value of the data that the instruction refers to indicates that the content item or the content derived therefrom is to be excluded from the target document; an assigner which assigns a first status, indicating that the content item concerned or the content derived therefrom is to be included in the target document, or a second status, indicating that the content item concerned or the content derived 15 therefrom is to be excluded from the target document, to the or each said portion of the target document in dependence upon the data that the instruction concerned refers to; and a second includer which, for each said portion of the target document, includes additional information in said target document indicative of whether the portion 20 concerned has been assigned said first status or said second status.

2. The electronic-document generation system according to claim 1, wherein the or each said instruction is defined In a markup language. 25

3. The electronic-document generation system according to claim 1 or 2, wherein the or each said instruction is defined in XML.

4. The electronic-locument generation system according to any of claims 1 to 3, wherein said additional information includes a colour or another symbol. 30

5. The electronic-document generation system according to any of claims 1 to 4, further including; a user interface operable to display said target document, or a document generated therefrom, in a first mode in which any such portion having said second 35 status is included in the displayed document, or in a second mode in which any such portion having said second status is excluded from the displayed document. 111

6. The electronic-document generation system according to claim 5, wherein said user interface is operable, in said first mode, to include any such additional information in the displayed document and, in said second mode, to exclude any such additional 5 information from the displayed document.

7. The electronic-document generation system according to any of claims 1 to 6, further including a tester operable, for the or each said instruction, to test the data concerned against a condition defined by logic, wherein said assigner is operable, for 10 the or each said instruction, to assign said first status to the corresponding portion if the data concerned satisfies the condition concerned, and to assign said second status to the corresponding portion if the data concerned does not satisfy the condition concerned. 15

8. The electronic-document generation system according to claim 7, wherein the logic for the or each instruction is defined in its respective instruction.

9. The electronic-document generation system according to any of claims 1 to 8, wherein said interpreter is operable, during generation of said target document, to 20 interpret a group of at least two said instructions, and wherein the system further includes: a tester operable, for each said instruction of the group in turn, to test the data concerned against a condition defined by logic, wherein said assigner is operable to assign said first status to the portion corresponding to the instruction whose data first 25 satisfies its condition, and to assign said second status to the or each other said portion.

10. The electronic-document generation system according to claim 9, wherein the logic for each said instruction is defined in its respective instruction. 30

11. An electronic-document generation system for generating a target document, the system including; an interpreter which, during generation of said target document, interprets at least one instruction of a first type and at least one instruction of a second type, each 35 said instruction referring to data and identifying a content item for use in generating said target document; 112 a first includer which, for the or each said instruction of the first type, includes the identified content item or content derived therefrom in a corresponding portion of said target document, and which, for the or each said instruction of the second type, includes the identified content item or content derived therefrom in a corresponding 5 portion of said target document or does not include any such content in the target document in dependence upon the data concerned; an assigner which, for the or each said portion corresponding to one of said instructions of the first type, assigns a first status, indicating that the content item concerned or the content derived therefrom is to be included in the target document, or 10 a second status, indicating that the content item concerned or the content derived therefrom is to be excluded from the target document, to that portion in dependence upon the data that the instruction concerned refers to, and which, for any portion corresponding to one of said instructions of the second type, assigns said first status to that portion; and 15 a second includer which, for the or each said portion corresponding to one of said instructions of the first type, includes additional information in said target document identifying that portion as having said first status or said second status, but which, for any portion corresponding to one of said instructions of the second type, does not include such additional information in said target document. 20

12. The electronic-document generation system according to claim 11, wherein each said instruction is defined in a markup language.

13. The electronic-document generation system according to claim 11 or 12, wherein 25 each said instruction is defined in XML.

14. The electronic-document generation system according to any of claims 11 to 13, wherein said additional information includes a colour or another symbol. 30

15. The electronic-document generation system according to any of claims 11 to 14, further including: a user interface operable to display said target document, or a document generated therefrom, in a first mode in which any such portion having said second status is included in the displayed document, or in a second mode in which any such 35 portion having said second status is excluded from the displayed document. 113

16. The electronic-document generation system according to claim 15, wherein said user interface is operable, in said first mode, to include any such additional information in the displayed document and, in said second mode, to exclude any such additional information from the displayed document. 5

17. An electronic-document generation system for generating a target document, the system including: an interpreter which interprets an instruction of a predetermined type, said instruction referring to working data and identifying a content item for use in generating 10 said target document; a first includer which, in dependence upon said data, either includes or does not include said content item or content derived therefrom in said target document; and a second includer which includes additional information in said target document, said additional information being indicative of how a change of said working data to 15 alternative working data would affect the content and/or structure of the target document.

18. The electronic-document generation system according to claim 17, wherein said instruction is defined in a markup language. 20

19. The electronic-document generation system according to claim 17 or 18, wherein said instruction is defined in XML.

20. The electronic-document generation system according to any of claims 17 to 19, 25 wherein said first includer is operable to only include said content item or said content derived therefrom if said working data satisfies a condition defined by logic.

21. The electronic-document generation system according to claim 20, wherein said logic is defined in said instruction. 30

22. The electronic-document generation system according to any of claims 17 to 21, further including; a third includer operable to include a link in said target document, said link being operable to access a data-changing device for use in changing said working data 35 to said alternative working data. 114

23. The electronic-document generation system according to any of claims 17 to 22, wherein said data includes a composite data item being an instance of a composite data type. 5

24. The electronic-document generation system according to claim 23, further including; a data-accessing unit operable to employ a predetermined definition of said composite data type to access said composite data item for use by at least one of said interpreter and said includers. 10

25. The electronic-document generation system according to any of the preceding claims, operable to generate the target document by executing a program and at least one subroutine in dependence upon said data, wherein the content and/or structure of said target document is dependent upon that data. 15

26. A computer-implemented method for generating a target document, the method including; interpreting at least one Instruction of a predetermined type, the or each said instruction referring to data and identifying a content item for use in generating said 20 target document; for the or each said instruction, including the identified content item or content derived therefrom in a portion of said target document even when a value of the data that the instruction refers to indicates that the content item or the content derived therefrom is to be excluded from the target document; 25 assigning a first status, indicating that the content item concerned or the content derived therefrom is to be included in the target document, or a second status, indicating that the content item concerned or the content derived therefrom is to be excluded from the target document, to the or each said portion of the target document in dependence upon the data that the instruction concerned refers to; and 30 for each said portion of the target document, including additional information in said target document Indicative of whether the portion concerned has been assigned said first status or said second status.

27. A computer-implemented method for generating a target document, the method 35 including: 115 interpreting at least one instruction of a first type and at least one instruction of a second type, each said instruction referring to data and identifying a content item for use in generating said target document for the or each said instruction of the first type, including the identified content 5 item or content derived therefrom in a corresponding portion of said target document; for the or each said instruction of the second type, including the identified content item or content derived therefrom in a corresponding portion of said target document or not including any such content in the target document in dependence upon the data concerned; 10 for the or each said portion corresponding to one of said instructions of the first type, assigning a first status, indicating that the content item concerned or the content derived therefrom is to be included in the target document, or a second status, indicating that the content item concerned or the content derived therefrom is to be excluded from the target document, to that portion in dependence upon the data that 15 the instruction concerned refers to; for any portion corresponding to one of said instructions of the second type, assigning said first status to that portion; and for the or each said portion corresponding to one of said instructions of the first type, including additional information in said target document identifying that portion as 20 having said first status or said second status, but, for any portion corresponding to one of said instructions of the second type, not including such additional information in said target document,

28. A computer-implemented method for generating a target document, the method 25 including: interpreting an instruction of a predetermined type, said instruction referring to working data and identifying a content item for use in generating said target document; in dependence upon said data, either including or not including said content item or content derived therefrom in said target document; and 30 including additional information in said target document, said additional information being indicative of how a change of said working data to alternative working data would affect the content and/or structure of the target document.

29. A computer program which, when executed on a computer of an electronic 35 document generation system, causes the system to carry out the method of any of claims 26 to 2. 116

30. A computer-readable storage medium storing a computer program as claimed in claim 29,

31. The electronic/document generation system according to claim 1, 11 or 17, and 5 substantially as hereinbefore described with reference to the accompanying figures.

32. The computer implemented method of claim 26, 27, or 28 and substantially as hereinbefore described with reference to the accompanying figures. 10 PRACTICAL LAW COMPANY LIMITED WATERMARK PATENT & TRADE MARK ATTORNEYS P31380AU01 15