diff --git a/bibliography.bib b/bibliography.bib
index 6d77de3..578b089 100644
--- a/bibliography.bib
+++ b/bibliography.bib
@@ -2307,6 +2307,26 @@
   file = {/home/charlotte/sync/Zotero/storage/BA342UGB/1263284.html}
 }
 
+@inproceedings{mishraProgrammingExerciseMarkup2023,
+  title = {The {{Programming Exercise Markup Language}}: {{Towards Reducing}} the {{Effort Needed}} to {{Use Automated Grading Tools}}},
+  shorttitle = {The {{Programming Exercise Markup Language}}},
+  booktitle = {Proceedings of the 54th {{ACM Technical Symposium}} on {{Computer Science Education V}}. 1},
+  author = {Mishra, Divyansh S. and Edwards, Stephen H.},
+  year = {2023},
+  month = mar,
+  series = {{{SIGCSE}} 2023},
+  pages = {395--401},
+  publisher = {{Association for Computing Machinery}},
+  address = {{New York, NY, USA}},
+  doi = {10.1145/3545945.3569734},
+  url = {https://dl.acm.org/doi/10.1145/3545945.3569734},
+  urldate = {2024-01-05},
+  abstract = {Automated programming assignment grading tools have become integral to CS courses at introductory as well as advanced levels. However such tools have their own custom approaches to setting up assignments and describing how solutions should be tested, requiring instructors to make a significant learning investment to begin using a new tool. In addition, differences between tools mean that initial investment must be repeated when switching tools or adding a new one. Worse still, tool-specific strategies further reduce the ability of educators to share and reuse their assignments. This paper describes an early experiences with PEML, the Programming Exercise Markup Language, which provides an easy to use, instructor friendly approach for writing programming assignments. Unlike tool-oriented data interchange formats, PEML is designed to provide a human friendly authoring format that has been developed to be intuitive, expressive and not be a technological or notational barrier to instructors. We describe the design and implementation of PEML, both as a programming library and also a public-access web microservice that provides full parsing and rendering capabilities for easy integration into any tools or scripting libraries. We also describe experiences using PEML to describe a full range of programming assignments, laboratory exercises, and small coding questions of varying complexity in demonstrating the practicality of the notation. The aim is to develop PEML as a community resource to reduce the barriers to entry for automated assignment tools while widening the scope of programming assignment sharing and reuse across courses and institutions.},
+  isbn = {978-1-4503-9431-4},
+  keywords = {automated grading,interchange format,markup language,notation,programming assignment,web service},
+  file = {/home/charlotte/sync/Zotero/storage/K7SJQZZK/Mishra and Edwards - 2023 - The Programming Exercise Markup Language Towards .pdf}
+}
+
 @inproceedings{mitamuraSeriousGamesLearning2012,
   title = {Serious Games for Learning Programming Languages},
   booktitle = {2012 {{IEEE International Conference}} on {{Systems}}, {{Man}}, and {{Cybernetics}} ({{SMC}})},
diff --git a/book.org b/book.org
index 15ab5f1..db5ac37 100644
--- a/book.org
+++ b/book.org
@@ -1311,7 +1311,30 @@ As mentioned in section\nbsp{}[[Test plan]], JSON is not the best format.
 It is very verbose and error-prone when writing (trailing commas are not allowed, all object keys are strings and need to be written as such, etc.).
 This aspect of usability was not the initial focus of TESTed, since most Dodona power users already use code to generate their evaluation files.
 Because code is very good at outputting an exact and verbose format like JSON, this avoids its main drawback.
-We wanted secondary education teachers to be able to work with TESTed however, and most secondary education teachers do not have enough experience with programming themselves to generate a test plan.
+However, we wanted teachers in secondary education to be able to work with TESTed, and they mostly do not have enough experience with programming themselves to generate a test plan.
+To solve this problem we wanted to integrate a domain-specific language (DSL) to describe TESTed test plans.
+
+We first investigated whether we could use an existing format to do so.
+The best option of these was PEML: the Programming Exercise Markup Language\nbsp{}[cite:@mishraProgrammingExerciseMarkup2023].
+Envisioned as a universal format for programming exercise descriptions, their goals seemed to align with ours.
+Unfortunately, they did not base themselves on any existing formats.
+This means that there is little tooling around PEML.
+Parsing it as part of TESTed would require a lot of implementation work, and IDEs or other editors don't do syntax highlighting for it.
+The format itself is also quite error-prone when writing.
+Because of these reasons, we discarded PEML and started working on our own DSL.
+
+The idea is not to supplant the JSON test plans, but to allow a JSON test plan to be transparently generated from a file written in the DSL.
+We also don't necessarily want the DSL to offer all the features of the JSON test plan.
+The DSL is meant for teachers creating basic exercises; they don't necessarily need all the advanced features of TESTed, and if they do, they can always still switch to the JSON format.
+Keeping the JSON test plan would also allow for different DSLs tuned for different types of exercises in the future.
+Our own DSL is based on YAML[fn:: https://yaml.org].
+YAML is a superset of JSON and describes itself as "a human-friendly data serialization language for all programming languages".
+The DSL structure is quite similar to the actual test plan, though it does limit the amount of repetition required for common operations.
+YAML's concise nature also contributes to the read- and writability of its test plans.
+
+The main addition of the DSL is an abstract programming language, made to look somewhat like Python 3.
+Note that this is not a full programming language, but only supports language constructs as far as they are needed by TESTed.
+Values are interpreted as basic types, but can be explicitly cast to one of the more advanced types.
 
 * Pass/fail prediction
 :PROPERTIES: