Silmaril logo  Please ✉️ mail or 📞 call to discuss your requirements.

This page is a placeholder. The ℞ system is new and the code and documentation are still being written.

The ℞ (recipe) ingredient management system

Sanity-checking for recipes


Figure 1: A prescription hand-written on 8th July 1970.℞ is short for the Latin word recīpe, pronounced ‘reh-see-pay’ or ‘reh-thee-pay’ or ‘reh-chee-pay’ depending on your culture. It means ‘take’ or ‘receive’, and it’s how doctors’ prescriptions used to begin, when they were handwritten. It instructed the pharmacist what ingredients to take and how to mix them for your medicine. Old recipe books used to start each recipe with the same symbol, and old pharmacy counter-books often contained recipes for food done the same way. Cookery recipes used to be known as ‘receipts’.

Figure 1: A prescription hand-written on 8th July 1970.


It’s become all too obvious over the years that publishers can no longer afford proof-readers or copy-editors. Nor can authors, certainly not on the percentages that publishers pay; and least of all cookery authors, who need to have every recipe tested many times, meaning there are constantly different versions floating around. Even if they do all the testing themselves, mistakes are bound to creep in.

℞ aims to help fix some of the usual suspects. These are common errors or problems that have been noted many times by cookery writers and editors (Flynn, 2020):

℞ can’t fix human problems. If you write that you need to “beat the eggs and sugar vigorously” when what you meant was to “stir the eggs and sugar gently”, no amount of software is going to correct you. Recipes need to be free of human errors before you publish them.

How it works

℞ is an XML system. That means the recipe has to be expressed in XML. If you’re going to be publishing it, it’s probably in XML already.

Each ingredient is specified with an xml:id to identify it (you can make these up), and a particular set of attributes to store the information, broken down into its component parts, eg

<ingredient quantity="220" units="g" dairy="butter" xml:id="butter"/>
<ingredient quantity="2" units="cloves" size="butter" vegetable="garlic" 
  treatment="crushed" xml:id="garlic"/>
<ingredient quantity="1.5" units="cups" meat="bacon" quality="diced" 
  xml:id="ham" comment="lardons"/>

Each time an ingredient is mentioned in the Method it uses the xml:id to refer to it.

Fry the <ing i="butter garlic ham"/> gently for five minutes

and it formats the instructions using the names of the ingredients you supplied

Fry the butter, garlic, and bacon gently for five minutes.

Don’t worry if this is all ελληνικά to you, your tech person will know what it means.

Because using XML is a standards-conformant approach, ℞ can be set up in any XML software on any system to be as raw or as sophisticated as you or your authors or editors need. Only the ingredient and reference elements need to be set up, so it can work inside your existing XML publishing system.

The software is written in XSLT3 and runs with any XSLT3 processor (eg Saxon). It’s currently alpha (α) status, which means most of it works, but some of it is still being developed, using as pilot examples. A useful side-effect of using the disaggregated data is that the XML files can be used directly as the print version of each recipe, styling them with CSS (additional formats could of course be written to do this differently).


℞ checks

that each ingredient gets used in the Method (or at least mentioned); and that all ingredients mentioned in the Method are in the List of Ingredients.

℞ (re)generates the List of Ingredients

in standard recipe wording from the disaggregated data in the attributes, so recipes are consistently formatted exactly as normal, eg (from the examples above):

℞ saves time

because it uses the standard XML ID/IDREFS cross-reference feature to refer to each ingredient instead of the author or editor having to retype the name of each item by hand.

℞ increases consistency and accuracy

because it formats the actual names of the ingredients regardless of the xml:ids you give them.

℞ checks the order

of the items in the List of Ingredients, that they match the order in which the ingredients are mentioned in the Method.

℞ extracts the ingredients into an index

, so if you are making a recipes website or publishing a book, your readers can search reliably, in the knowledge that everything there is listed, and nothing is listed that isn't there; it can also be used to generate shopping lists or grocery-site lookups.

℞ can be programmed to look up standard food databases

because it is consistent in storing the details of each ingredient (quantity, units, size, name, etc). If you have access to such a database, this lets you get the calories, fats, sugars, carbohydrates, fibre, allergens, and other data for labelling, hygiene, legal, and food security requirements.


A detailed paper describing the system (Flynn, 2020) was presented at the Balisage conference in the summer of 2020.

Current status:

Development is ongoing:


  1. Peter Flynn (2020) ‘Cooking up something new — An XML and XSLT experiment with recipe data’. In Balisage—The Markup Conference 2020, 27–31 July, Montréal, QC. Balisage Series on Markup Technologies (25)

Peter Flynn, 1 March 2021