Silmaril logo  Please ✉️ mail or 📞 call or 🦣 toot 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

Introduction

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.

Description

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 attribute to identify it (you make these up), and a particular set of other attributes to store the information, broken down into its component parts, eg

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

Each time an ingredient is mentioned in the Method it uses the xml:id value to refer to it in the i attribute of the ingref.

Fry the <ingref 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 http://xml.silmaril.ie/recipes/ 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).

Benefits

℞ 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.

Workplan

A detailed paper describing the system (Flynn, 2020) was presented at the Balisage conference in July 2020. A second paper, on the use of CSS to format the XML for print versions (Flynn, 2021), was presented at the same conference in August 2021.

Current status:

Development is ongoing:

Note on required and optional features

In this manual, the keywords must, must not, required, shall, shall not, should, should not, recommended, may, and optional have a specific meaning when shown in this typestyle, and must be interpreted as described in RFC 2119: (Bradner, 1997)  (Bradner, 1997).

When shown in normal type, these words keep their conventional contextual degree of meaning.

Special fonts and characters

In addition to the Requirement Levels above, the following typographic conventions are used to distinguish between different meanings:

StyleMeaningingredientan XML element type namemeatan XML attribute namebeefan XML attribute valueEMPTYan XML content modelrecipe.dtda file name

References

  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, Online. Balisage Series on Markup Technologies (25) https://doi.org/10.4242/BalisageVol25.Flynn01
  2. Peter Flynn (2021) ‘Printing recipes — Continuing adventures in XML and CSS for recipe data’. In Balisage—The Markup Conference 2021, 2–6 August, Online. Balisage Series on Markup Technologies (26)
  3. Scott Bradner (1997)Key words for use in RFCs to Indicate Requirement LevelsRFC 2119Internet Engineering Task Force, Reston, VA https://tools.ietf.org/rfc/rfc2119.txt

Peter Flynn, 1 March 2021