FITB exercises, old and new

[Rob Beezer]

"Old style" fill-in-the-blanks (FITB) are a problem type inherited from our
Runestone integration. We added support to help ease authors' transitions, with
no provision for enhancements nor much support. Now Brian W has put in a
massive amount of work to bring us a much more comprehensive "dynamic exercises"
suite.

There are six examples across the sample book and the sample article, which are
now the last of two impediments to getting schema errors down to zero on the
sample article with the dev schema (they are not going in the schema now!).
Options, in preferred order:

1. Use the repair phase to convert them to modern "dynamic exercises". Not
sure if this is even possible, given their reliance on regular expressions?

2. Remove the examples and retire the supporting code. Issue stern deprecation
warnings, drop a placeholder. This presumes that the Runestone side believes
books/authors are through converting.

3. Remove the examples and leave the supporting legacy code.

So, questions:

1. @Brian: is this at all possible?

2. @Brad: any intel supporting removing these entirely?

3. @Claude: this was your idea. Without testing examples, I predict bitrot
ensues. Which may or may not be worse than outright removal?

Reactions?

Rob

[D. Brian Walton]

1. The only issue that I would anticipate about converting during repair is that the "solution" defined in the old-style `setup` block is a test and not an answer. These questions do not actually have provided answers, just the regex that tests if a response is valid. At present, this would throw an ERROR (pretext-runestone-fitb.xsl line 468). It appears in `pretext-runestone-static.xsl` (lines 1189-1211) that the reg-expression is still being used as the displayed answer in generating the "solution", so if we *did* use the first answer, it would not be any worse than what already happens.

2. I think we definitely should remove the examples once we verify they convert appropriately. (I do not think the sample exercises implement the type of regular expression possibilities that are going to be of concern.)

Brian

--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAwVmRRWEFSUnE.1784157457%40pnsh.

[Rob Beezer]

Thanks, Brian. Yes, Claude had come to the same conclusion. "literal"
solutions will be OK, but regex solutions will be a small problem for the static
solutions.

I'd sent this as a follow-up and realized late last night it never went through,
I'll resend just now.

Rob

On 7/16/26 08:48, D. Brian Walton wrote:
> 1. The only issue that I would anticipate about converting during repair is that
> the "solution" defined in the old-style `setup` block is a test and not an
> answer. These questions do not actually have provided answers, just the regex
> that tests if a response is valid. At present, this would throw an ERROR
> (pretext-runestone-fitb.xsl line 468). It appears in `pretext-runestone-
> static.xsl` (lines 1189-1211) that the reg-expression is still being used as the
> displayed answer in generating the "solution", so if we *did* use the first
> answer, it would not be any worse than what already happens.
>
> 2. I think we definitely should remove the examples once we verify they convert
> appropriately. (I do not think the sample exercises implement the type of
> regular expression possibilities that are going to be of concern.)
>
> Brian
>

> email to pretext-dev...@googlegroups.com <mailto:pretext-
> dev%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/

> MTAwMDAwVmRRWEFSUnE.1784157457%40pnsh <https://groups.google.com/d/msgid/
> pretext-dev/MTAwMDAwVmRRWEFSUnE.1784157457%40pnsh>.

>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email

> to pretext-dev...@googlegroups.com <mailto:pretext-
> dev+uns...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/

> CAH7VRoJ0QSSF39m8XMBYVsKd8S3nqgRB%3Db-gaDhC6bxrNiyCRA%40mail.gmail.com <https://
> groups.google.com/d/msgid/pretext-dev/CAH7VRoJ0QSSF39m8XMBYVsKd8S3nqgRB%3Db-
> gaDhC6bxrNiyCRA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Rob Beezer]

On 7/15/26 16:17, 'Rob Beezer' via PreTeXt development wrote:
> 1.  Use the repair phase to convert them to modern "dynamic exercises".  Not
> sure if this is even possible, given their reliance on regular expressions?

Well, I am kinda new to all this. I thought a few minutes later I should just
put the question to my assistant while idle and on the clock. Response is
favorable. Only one gotcha it seems:

If an old style FITB has a correct answer that is a literal, say "42", then
everything is good. If the correct answer is a regular expression, then "static
back-of-book auto-solution loses its fill-in value". Not sure how weare
handling that right now anyway?

So we could

1. Repair old-style problems to new-style ones

2. Remove legacy code

3. Live with schema errors for a while, but eventually remove examples

4. Identify literal correct answers, and otherwise just put a placeholder in
the automatic solution for static forms. Maybe just reproduce the regex?

Or something like that.

Rob

[Andrew Scholer]

I presume this includes merging https://github.com/PreTeXtBook/pretext/pull/2936?

If that does not happen first, auto translating old fitb that include programming constructs is likely to result in broken problems.

--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAwZWtDTFI1Nk0.1784217376%40pnsh.

[Rob Beezer]

Using my best Andrew S imitation: "Probbbbably...?"

Had not thought that one through yet - thanks for the poke. ;-)

Rob

On 7/16/26 12:20, Andrew Scholer wrote:
> I presume this includes merging https://github.com/PreTeXtBook/pretext/pull/2936

> <https://github.com/PreTeXtBook/pretext/pull/2936>?

> email to pretext-dev...@googlegroups.com <mailto:pretext-
> dev%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/

> MTAwMDAwZWtDTFI1Nk0.1784217376%40pnsh <https://groups.google.com/d/msgid/
> pretext-dev/MTAwMDAwZWtDTFI1Nk0.1784217376%40pnsh>.

>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email

> to pretext-dev...@googlegroups.com <mailto:pretext-
> dev+uns...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/

> CACm44N8ccNoht1gRg%3DvGOVhyEY4hLa4RWLGDNoVvLqQ%3DLXQkyw%40mail.gmail.com
> <https://groups.google.com/d/msgid/pretext-dev/
> CACm44N8ccNoht1gRg%3DvGOVhyEY4hLa4RWLGDNoVvLqQ%3DLXQkyw%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Bradley Miller]

There are still a lot of old style fillins in the wild.  Mainly from authors who converted their book from RST using my old toolkit, and they have not gone back to update them, since, hey they work!

Automatically changing them would be nice.   Instructions for authors on how to use Claude to fix them would maybe go a long way toward encouraging them to do that work.

Brad

Brad Miller
Professor Emeritus, Luther College
Founder, Runestone Academy LTD
Blog: http://reputablejournal.com

Set up a time to meet with me.

To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAwaUpOcmdJYWw.1784230348%40pnsh.

[Rob Beezer]

Thanks, Brad. Working on this now. It may only be static solutions that are
affected, and so they "will just work (in HTML)" and that may be all those
authors care about right now.

But I need to do a bit more work to wrap my head around all of this...

Rob

On 7/16/26 12:49, Bradley Miller wrote:
> There are still a lot of old style fillins in the wild.  Mainly from authors who
> converted their book from RST using my old toolkit, and they have not gone back
> to update them, since, hey they work!
>
> Automatically changing them would be nice.   Instructions for authors on how to
> use Claude to fix them would maybe go a long way toward encouraging them to do
> that work.
>
> Brad
>
> Brad Miller
> Professor Emeritus, Luther College
> Founder, Runestone Academy LTD
> Blog: http://reputablejournal.com
>

> Set up a time to meet <https://fantastical.app/bonelake-Gj2i/meet-with-
> brad> with me.
>
>
>> On Jul 16, 2026, at 2:32 PM, 'Rob Beezer' via PreTeXt development <pretext-

> dev/1BC2A7D2-881A-4F0C-B204-E41F0F4A09CA%40runestone.academy <https://
> groups.google.com/d/msgid/pretext-dev/1BC2A7D2-881A-4F0C-B204-
> E41F0F4A09CA%40runestone.academy?utm_medium=email&utm_source=footer>.

[D. Brian Walton]

Rob,

If you are already working on the translation between old and new, I'd have to go back and look at whether the originals were authored with <var> instead of <fillin>, but the <setup> block of the RST style will almost directly translate to the <evaluation> block of the dynamic style. There should be no need for a <setup> block after conversion because none of these problems were randomized. I think these are the mappings needed:

<setup> maps to <evaluation>

<var> maps to <evaluate> (they were order matched, so no names are needed)

<condition><feedback></condition> maps to <test><numcmp|strcmp><feedback></test> (depending on the parameter, and the parameter value becomes the content of the *cmp element)

Your assistant probably already identified this.

Brian

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAwa3dJb1B1RVg.1784231776%40pnsh.

[D. Brian Walton]

Rob,

Since this other PR cleaning up the regular expression work relating to fill-in-the-blank exercises was mentioned, I have done some minor changes based on the current schema discussion to deal with some of the ambiguities that were noted: dealing with the bare-text case and allowing <de-evaluate> for the <variable> assignment's value and creating warnings about multi-answer-checks where there might have been some ambiguity.

I could tack them onto the existing PR without conflict, or I could make a new PR. Which would you prefer?

Brian

To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAwaUpOcmdJYWw.1784230348%40pnsh.

[Bradley Miller]

As I was just looking at some of the existing source, the originals do use <var> instead of <fillin>

Brad

Brad Miller
Professor Emeritus, Luther College
Founder, Runestone Academy LTD
Blog: http://reputablejournal.com

Set up a time to meet with me.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CAH7VRo%2BuAPQ2mxviogvaaBswvwDKEMmx%2BxuvzL6uksXvrH8npg%40mail.gmail.com.