Using codes instead of text fragments

Issue at stake

When inserting predefined values in a datafield or predefined answers in a Q&A question, it can be very tempting to use wording that can be inserted as such in the text of a document. For example, when a transport contract allows a delivery to be made in three different countries, you would be tempted to use the name of those three countries as the predefined value/answer.

This is not problematic when drafting a short, single-language document where the names of those three countries are only inserted into one specific clause. However, this approach has several drawbacks:

• In a multi-lingual document, you would have to use predefined values/answers per language, because the names of the countries differ per language.
  
• Writing condition statements in the body text of a clause becomes much more complex, because the conditions would change per language. For example, {#country^name = "United Kingdom": ... | "Germany": ... } becomes {#country^name = "Royaume-Uni": ... | "Allemagne": ... } in French.
  
• Writing enabled-conditions for a clause becomes almost impossible in a multi-lingual context, because enabled-conditions can only be drafted for a single language.
  
• Even in a single-language context, writing conditions becomes much more error-prone, because of the length and complexity of the names. For example, the likelihood of misspelling Czechoslovakia (French: Tchécoslovaquie) is quite high. Also, different variations of country names are used — for example, should you use “the Netherlands” or instead “Netherlands” ?
  
• With long values, reading condition statements becomes much harder because the condition part can get quite long.
  
• Managing small changes becomes much harder and error-prone.
  
  For example, assume that a transport contract allows the user to choose between normal delivery and premium delivery. The text that needs to be inserted into the document would then be either “delivery in accordance with the national carriers’ service levels” and “two-day guaranteed delivery at a premium rate”.
  
  Now assume that the delivery term is lowered to one-day delivery. Suddenly you will have to manually search for every occurrence of the text parts above, and manually change them — not only in the clauses, but potentially also in (conditions within the) Q&A.
  
• Text fragments cannot contain any conditions, concept-labels or datafields. Accordingly, those text fragments will not reflect changes in styling, concepts, datafields contents, etc.

Solution

The solution is to use codes instead of text fragments, optionally paired with labels and text snippets.

For example, in the transport contract referred to above, the normal delivery option could be referred to with code normal-delivery, and the premium delivery option with premium-delivery. Inside a clause, you would then write:

{#contract^delivery = "normal-delivery": .... whatever text needs to be inserted here for the normal delivery ... | "premium-delivery": ... text for the premium delivery stuff ... }

This indirection through a special code may seem like more work, but will not suffer from the scalability and management disadvantages outlined above:

• a code is much shorter, and therefore takes less time to type, and are less error-prone
• the document text associated with a code can be independently and centrally modified
• codes are language-independent, and can therefore also be used in enabled-conditions

Tips

When you frequently have to insert the same text fragment in conjunction with a certain code, it is beneficial from a management point of view to turn the text fragment into an external snippet, because such snippets allow for central updating. (If the entire conditional statement is frequently repeated, it is probably also a good idea to turn that entire statement in its entirety into an external snippet.)

Another tip is to associate (possibly translated) labels with the predefined value or answer. This avoids that the code itself would be presented to the end-user.