Sometimes the result of a variable needs to be another variable. For example, when composing a real estate sales contract,  there may be one seller or multiple sellers. The pronoun for multiple sellers is always 'they' or 'them', but for a single seller, the pronouns can be him or her or it (or the possessive 'his, hers or its').

   If grouped, the variables might look like this:

 [!S!Seller/Sellers]

 [!S!his/hers/its/their]

   Of course, for the grouping-with-multiple-choice-variables to work, the counts (and relative positioning) must be consistent. Here, they just don't  'match up'. There are two choices in the first and 4 in the second.

   Here are couple of possible solutions.

           [!S!Seller/Seller/Seller/Sellers]

           [!S!his/hers/its/their]

    There are several problems with this approach. First of all, it takes up a lot of 'real estate.' The longer a variable is, the more confusing it is to the end users. (This is one of the drawbacks of a 'plain-text' based system, and is one that most users are willing to accept for the myriad of other advantages, but we do not want to ignore the the point.)

   The second problem is that you don't necessarily know which 'Seller' will return which gender choice. If the second variable is answered first, it works out just fine. However, but unless you know from experience which one to click, you may be confused (or worse, may have confused your end user). (Of course, you can eliminate much of the confusion by creating a Mask.)

           [!S!Seller/Sellers]

           [!S![his/hers/its]/their]

 A bit more sophisticated nesting, listing various combinations of likely parties to a contract:

 [!S![Seller]/[Seller1] and [Seller2]/[Seller1], [Seller2], and [Seller3]]

 [!B![Buyer]/[Buyer1] and [Buyer2]]

 [!s![his/hers/its]/their/their]

 [!b![his/hers/its]/their]

Note also that there must be an identical number of choices for each of the groups. This is illustrated in the very last example where 'their' is repeated a sufficient number of times to match the number choices provided in the other group members.

As you can observe, the result of selecting the first choice of either group will be another multiple choice variable in the document. A second 'scan' of the document will be needed to complete it. Further, the value set in the second scan will not be saved along with the other values. This likely is not a major drawback, but it is something of which you should be aware.

Make sure to keep in mind the 'top-to-bottom' order in which Pathagoras processes variables. A variable that is nested in another variable may be processed away if the value for that variable 'blank' and you have set the 'Delete if Blank' switch to on.

With the above two points in mind, it may better to create <<*Options/Optional*>> text blocks to handle the placement of the 'final' variables. <<*Options/Optional*>> blocks are processed immediately (and automatically) after the document is assembled. That is when decisions regarding numbers of "major players" (parties, buyers, sellers, etc.) need to be made anyway. When properly used, <<*Options/Optional*>> blocks will result in the appropriate variables (and only the appropriate variables) being present when you begin taking other replacing them with the Instant Database routine. Further, the appropriate 'other' nouns, verbs and pronouns that are are also present. (You can copy and paste this example into a Word document and 'process' it to see the action described.)

Here is the way you could handle the "Seller" listings above using <<*Options*>> instead of nested variables:

<<*Options*!S!One Seller/Two Sellers/Three Sellers*[Seller]/[Seller1] and [Seller2]/[Seller1], [Seller2] and [Seller3]>>

. . . .(blah blah blah ). . . . but if <<*Options*!S![his/hers/its]/their/their>>  . . . (blah blah blah).