What should this be called? I had previously assumed that the community consensus was that the term “Parsons problem” could be applied to any block reordering problem. But not everyone uses the term this way, some limiting it to only coding problems. What term should we use? Stick with Parsons problems? Or call it something else? (And say in appropriate places that this includes Parsons problems as a subset.)
Should we have a simpler “DAG” representation for basic only-one-order solutions? Right now, using the DAG notation all keys need to be typed twice. A simpler format would allow authors merely to type the keys in the correct order.
As currently written, specific context usage features (things not intrinsic to an exercise definition, but rather that depend on how the exercise is to be used) are deliberately left out of the spec. The idea here is that context would be given to the implementation system as part of system authoring and use of exercises, not as part of the PIF definition. But perhaps this is inconvenient to actual use. An alternative is to put tags into PIF that allow problem authors (or instructors modifying a problem definition for use in a given course) to specify these contextual features. So far, these features have been identified as falling into this category:
Block numbering
A fixed order given to all users of the exercise (which ideally is generated randomly, but identically to all users)
The relative relationship between the drop zone for constructing the solution, and the block pool. The could reasonably be side-by-side, or one above the other.
Backtick (`) is currently used to delimit and separate toggles and textboxes.
Is backtick a good choice?
What do we do to escape when the backtick is needed to be used inside one of the choices?
As currently written, the DAG goes into a separate section from the block specification. Authors might like to combine the blocks specification with the DAG in some way. We can investigate supporting either of two options: (1) put the DAG closer to the blocks. (2) let the blocks list embody the DAG itself, perhaps by adding a tag to each block to specify the parent.