Please ✉️ mail or 📞 call or 🦣 toot to discuss your requirements. 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.
Introduction
℞ 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):
ingredients listed but never mentioned (eg “What am I supposed to do with this 50 g of butter left over?”);
ingredients mentioned but not listed (eg “Sugar? What sugar? Nobody said anything about sugar !”);
ingredients listed out of order, or not in any order;
ingredients listed under one name but referred to by another;
ingredients not named consistently between recipes in a collection;
ingredients that can’t be indexed, searched, or categorised.
℞ 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.
℞ 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).
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.
in standard recipe wording from the disaggregated data in the attributes, so recipes are consistently formatted exactly as normal, eg (from the examples above):
220 g butter
2 fat cloves garlic, crushed
1½ cups diced bacon (lardons)
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.
because it formats the actual names of the ingredients regardless of the xml:ids you give them.
of the items in the List of Ingredients, that they match the order in which the ingredients are mentioned in the Method.
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.
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 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:
natural language generation algorithm is now stable, both in XSLT and CSS, but is being tweaked as new foodstuffs are added;
the CSS for print rendering of the ingredients and references in XML is now stable;
nonce CSS is now generated to handle underscores in IDs (used to add flexibility when one foodstuff occurs several times) and to handle multiple IDs in one reference, which CSS cannot represent unaided;
new recipes are being added, and more are sought (subject to copyright agreement);
Development is ongoing:
the token lists of foodstuff categories are being expanded as new recipes are added to the pilot site;
discussions are under way with recipe editors on the categories;
print rendering CSS for non-ingredient elements is being improved;
exception handling in the natural language formatting is being examined with linguists;
an experimental method is being tested for dealing with multiple lists of ingredients and multiple methods in a single recipe (see, for example, Ragù, Béchamel, and Lasagne);
definition has started on the parameter requirements for an adaptive stepwise quantity/unit conversion method which will also handle cultural ingredient naming differences.
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.
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 namePeter Flynn, 1 March 2021