recipe-issues

From Microformats Wiki
Jump to navigation Jump to search

This page reflects externally raised issues about recipe microformat effort in development.

For issues regarding the hRecipe draft, please see and add to hRecipe.

This page also captures issues from the discussion that occurred on the microformats-new list (especially here, here, here and here). Some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Please read this page carfully before giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — Tantek

issues

Please add new issues to the bottom of this section by copy and pasting the Template. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.


template

Consider using this format (copy and paste this to the end of the list to add your issues; replace ~~~ with an external link if preferred) to report issues or feedback, so that issues can show up in hAtom subscriptions of this issues page. If open issues lack this markup, please add it.

Please post one issue per entry, to make them easier to manage. Avoid combining multiple issues into single reports, as this can confuse or muddle feedback, and puts a burden of separating the discrete issues onto someone else who 1. may not have the time, and 2. may not understand the issue in the same way as the original reporter. 

<div class="hentry">
{{OpenIssue}} 
<span class="entry-summary author vcard">
 <span class="published">2011-MM-DD</span> 
 raised by <span class="fn">~~~</span>
</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">«Short title of issue»</strong>. «Description of Issue»
** Follow-up comment #1
** Follow-up comment #2
</div>
</div>

resolved issues

resolved issue Alternative Ingredients We need a way to markup alternative ingredients.

  • This is not entirely straight-forward. We should put this off for a future revision.

resolved issue Photo The 'photo' property should be usable for elements containing the element <img>.

  • This format reuses the 'photo' property of hCard so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard (Human_vs._Machine_readable). This is an hCard problem and should not be discussed here.

resolved issue Reliance on Measure Microformat Mark-up of quantity would be enhanced by use of a measure microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable enough without explicit mark-up of values and units.

  • Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? Phae 08:44, 3 Oct 2007 (PDT)
    • The former. Andy Mabbett 13:10, 4 Feb 2008 (PST)
    • The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". Yde 08:59, 30 May 2008 (PDT)
  • The ‘quantity’ of an ingredient should be considered as a string which parsers may attempt to understand as required. A future ‘measurement’ format will be an obvious compound part in recipes, but it is not required for recipe to be specified usefully. [1], [2]

resolved issue Measure

  • Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? Lee Jordan 20:15, 4 Feb 2008 (GMT)
    • Volume->weight conversions won't be possible without a substantially more complex markup (e.g. 1 cup of sugar weighs substantially more than 1 cup of flour) Ciaran McNulty
    • The problem is not really substantial whereas a solution would require significant effort. Therefor the issue is considered outside the 80/20. ThomasLoertsch 15:44, 3 Dec 2008 (GMT)

resolved issue rel-license 2008-11-11 raised by ThomasLoertsch

  • Toby Inkster expressed concerns with rel-license in the following mail to microformats-new: http://microformats.org/discuss/mail/microformats-new/2008-August/001737.html. Currently it's not possible to scope a license to a single recipe on a page instead of the whole page. Until that problem is ssolved rel-license shouldn't be supported within hRecipe.
  • So either we throw it out of the first version of hRecipe or we add a hint that it MUST only be used ONCE per page.
  • After a chat with TobyInk in which he made it clear to me that adding rel-license to the whole PAGE is already perfectly possible I removed the element of the hRecipe format. ThomasLoertsch 15:26, 3 Dec 2008 (GMT)


closed issues

closed issue entry-title and entry-summary are not always semantically right and may not be good class names.

  • title and summary already used for a different purpose (in hCard and hCalendar/hReview/hListing). Read more.
  • recipe-title and recipe-summary suggested.
  • Changed to recipe-title and recipe-summary for now.

closed issue Scope of Recipes

  • Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? Andy Mabbett 14:53, 16 Nov 2006 (PST)
    • +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.Frances Berriman
    • Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. Cameron Perry
    • However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. John LeMasney
      • Recipe for Nitroglycerine (not recommended by Weight Watchers) ? Andy Mabbett 10:43, 1 Feb 2007 (PST)
    • The scope is determined by the recipe-examples research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the process. Tantek 07:39, 15 Mar 2007 (PDT)
      • Work is continuing on the recipe format now with the scope limited to food-based items only. Phae 08:44, 3 Oct 2007 (PDT)

closed issue Special sctructure for cooking details

  • Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [3]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) SudarshanP 06:46, 26 Jun 2007 (PDT)
    • I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behavior is common enough to warrant specific properties to hold it. Phae 08:44, 3 Oct 2007 (PDT)
    • I agree that this is out of scope. I closed this issue in preparation for the first draft version ThomasLoertsch Dez 2008

closed issue Ingredient Item/Quantity

TobyInk 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work. 

<li class="ingredient">3  eggs</li>

(note the double-space between '3' and 'eggs') is treated as a shorthand for: 

<li class="ingredient"><span class="quantity">3</span> <span class="item">eggs</span></li>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, item) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as: 

<ul class="ingredients">
<li>3  eggs</li>
<li>6 oz  self-raising flour</li>
<li>6 oz  caster sugar</li>
<li>6 oz  butter</li>
<li>1 tsp  vanilla essence</li>
</ul>

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

closed issue Alternative Ingredient Item/Quantity Optimisation

TobyInk 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but: 

<ul class="ingredients">
<li><var>3</var> eggs</li>
<li><var>6 oz</var> self-raising flour</li>
<li><var>6 oz</var> caster sugar</li>
<li><var>6 oz</var> butter</li>
<li><var>1 tsp</var> vanilla essence</li>
</ul>

Or is this stretching the meaning of <var> too much?

closed issue Measure

  • The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See BBC weather example Lee Jordan 20:00, 4 Feb 2008 (GMT)
    • The linked example doesn't include a SUP tag, the degree symbol can just be used as normal in most cases Ciaran McNulty

closed issue nutrition

per serving. May be part of the measure microformat in future.

  • +1. Nutritional information is quite important for a lot of people and is inside the 80/20. It should be included as an optional element. The problems are: which nutritional information exactly? A common denominator is calories, proteins, carbohydrates and fat. That's also what european law demands as information on packaged food. Most sites that I visited only list calories as nutritional information (if any). Since Calories are a somehow superordinate concept for proteins, carbohydrates and fat that's fine. Allrecipes.com is quite extreme with a huge list of nutritional information - clearly outside 80/20 IMHO. Another problem: although Calories are the most popular term, the measure is deprecated in favor of Joule. hMeasure too uses Joule. I'd therefor propose to add the optional element nutrition and subelements calories("mandatory") in Joule,fat("optional"), protein("optional"), carbohydrates("optional"), and dietary fiber("optional"), those all in grams. --ThomasLoertsch 15:16, 01 Oct 2008 (CET), modified 09.Oct 2008 and 13.Oct 2008
    • +1 for a nutrition element. However, I would like to change the subelement calories to energy, as that would allow using either calories or joules (using hMeausere) and it feels weird to state joule in an element called calories. --Yde 05:57, 11 Oct 2008 (PDT)
    • I felt the same and energy is a good idea. However I think we should stay with Joules, since hMeasure doesn't include Calories and we don't want to get things too complicated.
      • hMeasure allows any units to be used. The unit property is defined as an opaque string. The draft spec does allow parsers to delve into this otherwise opaque string and assign meaning to it, and strongly suggests that any parsers which do this support all SI units and prefixes. However, it does not prevent authors from using non-SI units, such as calories. TobyInk
      • You're right. Still, wouldn't it make more sense to go for the standardized Joule instead of the deprecated and non-standardized Calories?
        • I think a lot of people are using calories instead of joule (or both), so IMO it would be too restrictive to only allow joule. --Yde 02:50, 18 Oct 2008 (PDT)
    • But do we really decide for the multi-element proposal outlined above? Or should we rather go for a simple and single nutrition element, optional, without subelements (and with hMeasure Joule)? I'm still undecided myself. ThomasLoertsch 12:02, 13.Oct 2008 (CET)
    • I added a third version of encoding nutrition to the proposal. It is rather flexible and introduces only one new element. I also made Joules a preferred, but optional unit, so Calories are possible now too. ThomasLoertsch 12:55, 5.Nov 2008 (CET)

For the record: these are 3 possible encodings for nutrition. see abve for the final version

      • The element SHOULD use the unit Joules from measure, but any other unit like Calories is also possible.
    • A more elaborate version would add information for fat, proteins, carbohydrates and dietary fiber - but this may already be out of the 80/20 range. Of course a lot more nutritional values would be available but these seem definitely outside 80/20.
    • Nutritionnutrition. optional
      • Energy. energy. optional. Joule measure
      • Fat. fat. optional. gram measure
      • Protein. protein. optional. gram measure
      • Carbohydrates. carbohydrates. optional. gram measure
      • Dietary fiber. dietary fiber. optional. gram measure
    • A third version would model nutritional information like ingredients:
      • Nutritionnutrition. optional
        • Item. item. optional. text. measure.
        • Quantity. quantity. optional. text. optionally measure.
        • Note. note. optional. text.
    • The first version probably fits the 80/20 rule best. The second version gives more guidance and encompasses most real world usecases. The third version is very flexible, without adding many new elements.

ThomasLoertsch 15:54, 11.Nov 2008 (CET)

In a private discussion TobyInkster enlightened me: The idea behind hmeasure is that it has four key components:

  • item: the thing that you are measuring (e.g. The Great Wall of China)
  • type: the aspect of it that you are measuring (e.g. its height, its width, etc)
  • unit: the unit you are measure it in
  • num: the measurement itself
  • By embedding the "nutrition hmeasure" inside the hrecipe, you are implicitly setting "item" to refer to the recipe itself - so the thing that we are measuring is the recipe. So then "type" allows us to specify what aspects of the recipe we are measuring (Energy, dietary fibre, fat, etc). E.g.
<div class="hrecipe">
   ...
   <p class="nutrition hmeasure">
     <span class="type">Energy</span>:
     <span class="num">1000</span>
     <span class="unit">J</span>
   </p>
   <p class="nutrition hmeasure">
     <span class="type">Dietary Fibre</span>:
     <span class="num">4</span>
     <span class="unit">g</span>
   </p>
</div>

ThomasLoertsch 16:01, 11.Nov 2008 (CET)

closed issue note

The 'note' property is only useful in some rare cases and might not fit the 80-20 rule.

  • We might want to start as simple as possible and leave this out for a future revision.
  • People often put some of the very basic preparation steps into the ingredients list. For example, ingredients lists sometimes read like "one onion, finely chopped".
  • +1. note should stay as an optional value. There are so many ways to define ingredients that it seems useful enough to fit into the 80/20. --ThomasLoertsch 15:26, 01 Oct 2008 (CET)

closed issue optionality 2008-10-13 raised by ThomasLoertsch

Instead of note I'd rather remove the optional property. Information about the optionality of an ingredient can easily be added in the note field, e.g. together with suggestions for a possible replacement. --ThomasLoertsch 12:59, 13.Oct 2008 (CET)

  • Since nobody disputed this I added it to the October 2008 proposal and subsequently to the December 2008 draft version. TomLurge Dec 2008

closed issue make method optional 2008-07-15 raised by TobyInk

For informally or concisely written recipes, the method is often left out. Could we either make this optional, or have an optimisation such that if the method is absent, the entire text of the recipe is taken to be the method. TobyInk 02:53, 15 Jul 2008 (PDT)

  • e.g. salad, sandwich and smoothie recipes don't often require a method to be useful.
  • +1 for making it optional. Although most recipes rely heavily on a method there are indeed those where it isn't necessary. If 80/20 does mean that easy or simple usecases should be facilitated it would be in line with the principal to make the method optional. And it wouldn't hurt anybody either. --ThomasLoertsch 15:04, 01 Oct 2008 (CET)
  • I don't know... Making the method optional would make "I like to eat cheese for supper" a technically valid recipe, but it provides no value as a recipe. In other words, I am concerned that this will lead to people using the format for things it was not intented for. I don't know if this will happen, but we need to take it into consideration. --Yde 06:17, 11 Oct 2008 (PDT)
  • I think there's no technical way to prevent misuse (and no other way either ;-). --ThomasLoertsch 12:52, 13.Oct 2008 (CET)

closed issue preparation-time 2008-10-01 raised by ThomasLoertsch

Make preparation-time plural and add an optional preparation-time-note element inline to preparation time

  • preparation-time (optional, plural)
    • preparation-time-note (optional, singular)

There are often times additional to the main preparation time i.e. the time the dough needs to rise. When scanning a recipe for practicality - i.e. your guest are coming in 4 hours - this is a very important information. Allowing preparation-time to be used more than once per recipe and adding an optional note element would allow great flexibility in stating such details while staying simple. It could also be used to give times for different parts of a recipe like cake and topping or to differentiate times for preparation, waiting and cooking. --ThomasLoertsch 15:05, 01 Oct 2008 (CET)

  • That's a good point. But how do we semantically connect the preparation time and a specific part of the recipe? --Yde 06:25, 11 Oct 2008 (PDT)
  • In the absence of sections for ingredients or method steps I see no way to connect the preparation time and a specific part of the recipe in a standardized manner. But the same applies to ingredients and method steps. I guess a solution would need some quite involved sectioning constructs. In my feeling this is not such a big problem that it justifies further constructs. ThomasLoertsch 12:25, 13 Oct 2008 (CET)

closed issue Problems with programatically marking up ingredients 2008-10-19 raised by Kenn Wilson

While I understand the need for a item element within an ingredient, in practice this may be difficult to implement. The quantity element suffers from the same problem, but it's optional, unlike item. The problem occurs when marking up existing recipes for display. A list of ingredients pulled from a database is trivial to mark up with ingredient but it's nearly impossible to add the required item with a high degree of accuracy. Doing so would require being able to parse each ingredient and identify and separate the quantities and items, which is only really possible if you know in advance every form the quantities will take so you can accurately pattern-match them. For a real-world example, I'm currently building a site for a good-sized (9,000+) recipe collection. These recipes come from a number of sources and contain many different units of measure. While I can match for things like "oz", "cup", etc, and assume that what follows is the item, this is error prone and doesn't take into account things like "pinch", "dash", and the nearly endless list of other possible terms I may encounter. I'd like to suggest that item be made optional, as the other child elements of ingredient already are. People coding recipes by hand or who are otherwise able to separate these things may use them, but those of us who are unable to do this can omit them while still outputting valid recipe microformat. Kenn Wilson 11:29, 19 Oct 2008 (PDT)

  • The way I've implemented this in Cognition, any markup within ingredient is optional — ingredients can be just an opaque string if desired. TobyInk 01:49, 20 Oct 2008 (PDT)
  • Kenn's case is indeed a convincing argument. I changed the october08 proposal accordingly. It's now inline with Cognition too. ThomasLoertsch 12:59, 5.Nov 2008 (CET)


closed issue ingredients should not be required2008-12-04 raised by TobyInk

ingredients should not be required. When I proposed this property I intended that it be an optional wrapper for one or more ingredient properties. Whatsmore, I proposed that an optimisation exist such that any direct child elements of ingredients are assumed to be ingredient properties. That is, it was intended to streamline hRecipe markup. The way it is currently specced it does the opposite: it forces authors into using a superfluous wrapper around their ingredient list. I propose the following changes to the spec:

  • 3.2 Schema: Define ingredients as: "optional. wrapper for 1 or more ingredient elements."
  • 3.3.7 ingredients: change definition to:
    • The element is identified by the class name ingredients.
    • A Recipe MAY include one or more ingredients elements.
    • The element by definition includes 1 or more ingredient elements. Any direct child elements which are not marked with the ingredient class are assumed to be ingredient elements anyway.
  • 3.3.8 ingredient: remove the requirement that it must be the child of an ingredients property.
  • Agreed complete about not requiring ingredients as a property. I don't think it would fit gracefully with marking up: Take some onions, crushed garlic, fry them together, then sprinking liberally with cinnamon for a sweeter onion base.. --BenWard 00:47, 5 December 2008 (UTC)
    • I don't know. Couldn't I further your example to conclude that 'title' and 'method' should be optional as well? But what's the purpose of a recipe format if it doesn't enforce the simplest structure? title, method and ingredients all seem essential to me. Method has already ben made optional, leaving only title... TomLurge 13:04, 9. December 2008 (GMT)
  • I'm also unsure that saying 'any child is assumed to be an ingredient' is going to work. Seems unclear. Having an optimisation for saying that <ul class="ingredients"> treat all child li elements as an ingredient makes sense, but generically I disagree. --BenWard 00:47, 5 December 2008 (UTC)
    • So, a question here is rather than have two property names for pluralisation, could instead have a rule that has ingredient treated as a list when on a list element, but singular otherwise? --BenWard 00:47, 5 December 2008 (UTC)
      • This could work. The only circumstance where it would fail would be if some very strange people wish to markup a single ingredient as a list (i.e. <ul class="ingredient"><li class="item">Onions</li><li class="note">Chopped</li></ul>). TobyInk 15:18, 5 December 2008 (UTC)
    • The recipe you gave as an example could be written: <p class="hrecipe"><span class="ingredients method">Take some <b>onions</b>, <b>crushed garlic</b>, fry them together, then sprinkling liberally with <b>cinnamon</b> for a sweeter onion base.</span></p>. But certainly <ul> was the element I had in mind for class="ingredients". TobyInk 15:18, 5 December 2008 (UTC)
    • Can we make them either/or? Either ingredients or (a list of) ingredients? TomLurge 11:53, 9. December 2008 (GMT)
    • Thinking about it again: how much do we loose if we discard ingredients completly, leaving only ingredient? It would be "1 or more", maybe even "optional" (I don't care anymore ;-), with optional subelements. The only drawback is that putting more than one ingredients into a singular-named field is counter-intuitive but IMHO that's not extremely upsetting TomLurge 13:15, 9. December 2008 (GMT)
  • Sorry I messed up your proposal, Toby - I got you wrong! But I'm not sure I agree. Adding an element doesn't necessarily make a format less readable. Redundancy can help understandability. A very concise format may be simple from one point of view, but it might not be easy to understand and use. See for example very terse code... TomLurge 11:51, 9. December 2008 (GMT) (But see my proposal above)
    • I agree with your above proposal (dropping ingredients). My reasoning is that if there is demand for such redundancy, it or something like it could be worked into a future iteration, but for now working with the explicit, optimisation-free pattern would be better for development. Personally I don't see demand for it (I think marking explicit ingredients os fine), but removing it now would not prevent it being revived later. --BenWard 18:52, 9 December 2008 (UTC)
      • Okay, I changed the draft accordingly. It's always easier to add an element than to remove it subsequently. I'm not particularily fond of my wording explaining the use of a single ingredient element for each ingredient when used together with hmeasure. Maybe a native speaker can check and improve that. TomLurge 10:16, 11. December 2008 (GMT)

related pages

Retrieved from "http://microformats.org/wiki/index.php?title=recipe-issues&oldid=36711"