Subsection 4.12.7 Fill-in-the-Blanks Exercises
As of 2022-06-14 a major effort is underway to provide comprehensive markup for fill-in-the-blank problems. Until then, there is transitional markup intended only to supply a migration path for projects originally authored for Runestone servers (Chapter 32). So (a) our documentation is sparse, and (b) there will be no backward-compatible improvements. So in particular, new projects should wait for the new markup. Also, studying examples may be a useful way to augment what is described here.
A
<statement> is enriched with empty <var/> elements which will render as the blanks in the problem.The signal for a fill-in problem is a
<setup> element containing a sequence of <var> elements. Each <var> contains a sequence of <condition> elements that describe possible values (via regular expressions) which might appear in a blank. The first condition describes the correct answer(s), and then the subsequent conditions are descriptions of probable incorrect answers. Each <condition> has a <feedback>. So the first condition to match an entry provided via a blank will be noted as correct or incorrect, and its feedback will be relayed.The
<var> of the statement and the <var> of the setup are in a 1-1 correspondence, which establishes how the setup is associated with a blank. The <var> in the statement may have a @width attribute whose value controls how many characters would be visible in the blank.A static version will include an automatic
<solution> which “fills in” each blank with a correct answer, and then duplicates the feedback text, in order.
