PATHAGORAS™ Users' Guide, Part 4

  Section D. Document Assembly:
 Creating a Document Assembly System
Adding Clauses to a Book; Clause Naming Techniques
If you wish to proceed to a particular subject on this page, please click
on one of the below links:


Summary:
    If you have run through any of the PATHAGORAS introductory exercises or the Wow! Tour, you have gotten a taste of how document assembly works (and how easy it can be). It's either 'check off the clauses from the checkbox screen', or 'type the clause name onto the editing screen and press <Alt-G>'. Even if you haven't tried any of the exercises, if you have read other sections of this User's Guide, you are somewhat familiar with the process. Now it is time for you begin a document assembly system of your own.

Getting Started
     The first things you need for a document assembly system are terms to assemble. It doesn't matter how many you have. It doesn't matter how long they are or what you call them. You just need more than one to have a viable system. Actually dozens are better if you want to get a good sense of the process.

     If you don't already have a set of terms in mind, make some up. Chances are you have an existing document which has been a "base" for creating other documents. Use that one for now. Let's break it up into its various major components, and then add variety to the clauses to fit the various situations that you might encounter in attending to a client or customer's need. 

    The technique is easy. It's just  'Highlight & Add.'
 
    Recall in Part 4a we discussed the concepts of 'Books' and 'Libraries.' We discussed that Pathagoras can draw clauses from two distinct sources:

     (a)  'glossaries' (collections of clauses all within a single document) and

     (b) 'folders of terms' (simple document folders where the housing individual clauses of the document-to-be.

     PATHAGORAS doesn't care which kind of book you choose to use. Initially, creating separate documents and storing them all in a folder is the easier way to go, but see this link for a list of the benefits of glossaries over folders.

     So highlight some text. Any text is okay, but for now find a good paragraph and highlight it. At this point you have a choice:

   (a) Save the highlighted text as a separate document.  See this link in Part 3 of this Users' Guide for details on the 'Highlight & Add' technique for creating a new document.  If you prefer to make separate documents out of the clauses, just make sure that all of the clauses saved for assembly of a particular document are stored in the same directory. (PATHAGORAS can read the contents of any folder, but it can only read one folder at a time.)

   (b) Highlight the text and save each clause to a glossary.  If you don't have a glossary yet, you will find it incredibly easy to create one. See Part 5 for the details and the instructions concerning the creation and maintenance of glossaries.


     As you are creating and naming clauses for use in your own document assembly systems, consider carefully the names you give to your clauses.  They will have a significant bearing on the way you ultimately will use the system. See the discussion in the below box for more information on this important topic.
     Definition / Discussion: 'Prefix/suffix naming convention.'

    Since the (welcomed) demise of the "8.3" limitation of DOS and early versions of Windows for naming documents, computer fans have been able to name documents without significant restriction. Despite the removal of length limits, however, certain names are clearly better than others.  For alphabetization reasons, "Kennington, Response to Offer" is better than "Response to Offer in the Kennington file."  "Letter to Mom, Aug 2004" is at least marginally better than "Dear Mom, Please Send Money, Aug 2004" Nevertheless, there is a certain elegance to keeping names as short and simple as possible. 

     If the user intends to take advantage of PATHAGORAS ' Instant Open feature (found in the PathSmart module) or the mouseless <Alt-G> method to recall a document from a SmartPath or glossary, the shorter the name, the easier it will be to take full advantage of these features. The reason is simple--if the name is long or complex, it is more difficult to remember its spelling. Was there a comma after the last name? Were there spaces between the words? An underline? So simpler and shorter is probably better.

     When it comes to document assembly, shorter is definitely better. The examples that ship with PATHAGORAS have names like 'wil100' and 'boc225.'  While these names inherently mean nothing, once the operator 'memorizes' that wil100 is the preamble to a will, it is easy to recall that preamble to the editing screen.

     The argument can be made that "Will, Preamble" is at least meaningful and therefore better. True for this instance, but what happens when it is a clause dealing with the "statutory powers of the personal representative." "StatPowPersRep"? Personal Rep Powers"? Who can be expected to type, much less recall, that, accurately?  Code names are no worse that long names for instant recall purposes.

    Using a printed checksheet helps to reduce problems. With such a checksheet, the author of the document would check all of the desired clauses from the checksheet, The computer operator would then electronically 'check-off' on the computer screen the parallel clauses. If later the attorney wants to add "wil122a" (Special Gifts) into the middle of the assembled document, the computer operator could simply type "wil122a" at the proper insertion point, and press <Alt-G>. The clause is instantly called in.  There comes a point that a perfectly well-named document cannot effectively be used in a document assembly system.

    By trial, error and practical experience, the 'prefix/suffix naming convention'  has been adopted by PATHAGORAS (and many other programs) as the 'best' way to implement clause-based document assembly. As used in Pathagoras, the prefix/suffix naming convention  means that a clause's name must begin with a two to four letter prefix immediately followed by a 3 or 4 digit numerical suffix. (The suffix can be further 'suffixed' by additional letters.  'BOC103', 'pre3433a' and 'Dz766first' all meet the convention. 'B123', 'Clause765' and '100boc' do not.  Any name is acceptable, but only those that follow the above pattern will allow you to maximize PATHAGORAS ' most powerful document assembly features.

    Please note the following:

  • PATHAGORAS maintains a table of the associations between a prefix and the corresponding glossary. It uses the naming convention to quickly identify a term and locate the glossary in which it exists. So, when <Alt-G> is pressed at the end of a terms name, PATHAGORAS looks for the character-digit pattern.  If the initial characters are between 2 and 4 in number, followed by three or four digits, if looks for the prefix in the table and goes directly to the proper glossary. If you are not using the above described naming convention, you will not be able to take advantage of PATHAGORAS' full powers.
  • Some names do not lend themselves to prefix/suffix naming because they do not 'belong' to a particular glossary. The address to the Clerk of the Court, or the executive officer's signature block, simply are not namable as "wil 345" or "con221". These 'generic terms' belong in a 'general glossary' which Pathagoras will also automatically look into upon an <Alt-G> call. See Position #1 Glossary in Part 5 of this Users' Guide.
  • Please note: a name such as 'Contract100' is a perfectly acceptable name for a clause. However, PATHAGORAS will not be able to instantly discern that "Contract" is a prefix. Therefore PATHAGORAS will not be able to instantly link an <Alt-G> call to the glossary that contains that term.  Don't panic however: If asked via <Alt-G> to find a term such as "Contract100", PATHAGORAS will certainly still find it,  but it will take several seconds longer for do so than if it were locating a term such as "Contr100" and 'contr' were

     PATHAGORAS is flexible enough to work with any of Word's naming styles and rules. Further, the naming convention described above pertains only to the document assembly aspects of Pathagoras, not disk navigation, saving of completed documents, general correspondence, etc. In most cases, the name of the document is not important. (But see the second paragraph in this box discussing Pathagoras' "Instant open" feature.) But as one uses the system (especially if making <Alt-G> calls) to build documents from clauses, the benefits of the 'prefix/suffix naming convention' will become apparent, and the deficits of other naming systems and programs more pronounced.
   So, whether you adopt the prefix/suffix naming convention, or any other naming device you choose, keep the names short and keep them consistent. Think about how they will appear when alphabetized in either Word's standard display or PATHAGORAS ' Checkbox form and name them accordingly.

   See Part 4g of this guide for the specific steps you must take to take a book and place it on a shelf in your active library.

Building you first document:
    With document assembly terms now in a book and the book now on a shelf in your library, let's build a document. Click the DocAssembly icon (the third one from the left in the PATHAGORAS menu). Double click in the option circle next to the name of your new book which will appear in the list at the left. PATHAGORAS' checkbox screen will then display.

    Select the terms you want to assemble into a new document.  Press the <Assemble> option and then the <Next> button. Even if the actual document may make no sense to you (if you randomly selected clauses), or if the terms are spaced incorrectly, at least you can see the process, and your contributions to it.  To edit terms within a 'folder of terms,' simply open the document and edit as you would any other document. To edit terms in a glossary, see Section 5b.

    See Part 4e for alternative assembly methods using your newly created book.
Part A of this Section 4 provides the new and experienced user an introduction to document assembly.
Part B of this Section 4 discusses the two main document assembly screens.
Part C of Section 4 discusses the engine behind the surface: the Settings screen.
Part E discusses alternative document assembly methods.
Part F demonstrates how to personalize a document or form for a specific client or customer.
Part G takes you step-by-step through the process of adding 'books' to your libraries.

View Part 1 of Users' Guide (Introduction)
View Part 2 of Users' Guide (PathSmart module)
Return to Part 3 of Users' Guide (SaveSmart module)
Continue with Part 5 of Users' Guide (Glossary module)
View Part 6 of Users' Guide (Database Link module)
View Part 7 of Users' Guide (Other Features)

Revised 10/08/03