[XML-SIG] DTD for recipes

[Andrew M. Kuchling]

Lars Marius Garshol writes:
> - Metadata in general: I think the DTD should in fact hard-wire
> optional elements for what we can usefully standardize (possibly in a
> separate metadata section), and then allow for extensibility, either
> through generic property name/value (and maybe values) sets or
> possibly ANY content models. (Possibly both.)

	Maybe use RDF?  I don't know anything about metadata, and so
am completely at sea on this issue.

> - Number of servings: another good thing about XML: we should be able
> to do automatic scaling of the ingredients (within reasonable limits,
> of course)

	We do need to store the number of servings for the recipe as
given, though, to know what to scale it to; I don't think software
could look at a recipe and say "Aha!  10 people!".  Servings might be
measured in various units: serves 10 people, makes 36 cookies.  

> - Ingredients: I think we need different kinds of ingredient
> elements, classified by amount type: exact, approximate and optional.

	Ah, "optional" is a good idea; I'll add an 'optional'
attribute to the ingredient element that defaults to "no".  Still
don't know what to do about approximate amounts, though.

> - Also, alternatives for ingredients would also be nice, as would
> some way of referring to the alternative from the steps, so that
> presentation software can choose the correct alternative

	Hmm... Should the ingredient section of the DTD be changed to
( (ingredient | alt-ingredients)* | group*).  The content of the
'group' element would then be:

<!ELEMENT group ( (ingredient | alt-ingredients)+ )>

The 'alt-ingredients' element would just be a list of ingredients.
I'm not sure how to refer to ingredients.

	Here's another design question: is it a good idea to have
explicit elements for each section?  Right now recipes are defined
like this, with the sections being only implicitly visible:

<!ELEMENT recipe (title, author?, source?,
                  (ingredient*|group*),
                  step*, note?) >

Contrast this with HTML, where you have HEAD and BODY elements,
explicitly breaking the document into those two sections.  In other
words, should the above be changed to something like:

<!ELEMENT recipe (metadata, ingredient-list, instructions)>

	I suppose this would make some processing jobs easier, but
have no strong feelings on this.

> - I think we need something more advanced than 'note', although I
> have no immediate ideas for the form it should take.

	<shrug> Anyone producing a cookbook from this DTD will have
their own ideas for what textual commentary should accompany a recipe;
I'd be happy with just providing an application-specific class
attribute for 'note'.

> - Also, some means of referring to other recipes from a step would be
> nice, as in '<step>Prepare some white sauce, as described in
> <step-recipe href="white-sauce.xml">the recipe for white 
> sauce</step-recipe>.</step>'

	Yes; it should be possible to link to other recipes in the
same document, or to a recipe in another collection.

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
The nice thing about list comprehensions is that their most useful forms could
be implemented directly as light sugar for ordinary Python loops, leaving
lambdas out of it entirely. You end up with a subtly different beast, but so
far it appears to be a beast that's compatible with cuddly pythons.
    -- Tim Peters, 6 Aug 1998