Hi all, as I already posted here we're planning to implement hRecipe at "essen & trinken" [1]. I think hRecipe is in quite a good shape already. Cognition [2] has recently included "experimental support for the proposed hRecipe microformat" (though the document [3] is a bit vague about what exactly they make required and optional respectively). As I'm not sure (and most probably nobody is) how the standardisation process carries on, this experimaental support at least seems to be a viable option to get things moving. But it's also a reminder that there are some open issues which somehow have to be resolved. And maybe there isn't so much more to clear out? But before I give my comments to the open issues please let me open another one ;-)
* Suggestion: idle period / off-time / rest period / unattended time You have to help me with the right english term here. What I mean is the time that i.e. the dough needs to rise. When scanning a recipe for practicality this is very important information. I'd like to suggest this as an optional element. Please comment! Now my 5 cents to the issues as summarized in recipe brainstorming [4]. I'm trying to comment on all open issues, to help sort things out: * Date published I would leave the use of the datetime-design-pattern as optional (should). Although it means stopping halfway by making the date machine retrievable but not machine readable it is still better then nothing. And the issues around datetime-design-pattern are not trivial. * Ingredient TobyInk proposes an optimization for Ingredient which makes sense, but... first I wonder how much harder the optimization makes it to develop parsers. And second the rule should be extended: if there is no <item>, <ingredient> IS the <item> AND there cannot be any further <quantity>, <note> or <optionality> for that ingredient. All in all that sounds too complex to me, an accomplishment not worth the effort and therefor not in alignement with the 80/20 principal. So I'm against it (not violently, though). * Method TobyInk proposes to make the method 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. Since making it optional doesn't hurt anybody I agree with TobyInks proposal. * Suggested: Method > Steps or Method-Step I'm against that. Outside 80/20. xHTML can do that alright. Also see below. * Suggested: Calories I'm all for that. Our site has nutritional information for calories, proteins, carbohydrates and fat. That's also what european law demands as information on packaged food. Most sites that I visited only listed calories as nutritional information if they did at all. Allrecipes.com is the other extreme with a huge list of nutritional information - clearly outside 80/20 imho. Calories are a superordinate concept for proteins, carbohydrates and fat. Nuitritional information is quite important for a lot of people. I think calories are inside the 80/20 and should be included as an optional element. A minor issue though: calories or joule? Most sites use Calories, but the term is deprecated, and hMeasure uses Joule. * Measure / use of hMeasure There are a lot of units typically used in recipes that do not make much sense in most other cases and therefor most likely will never make it into a 80/20-aware measure-microformat. This is a deliberatly short list: - glass - leave - pinch - tablespoonful - teaspoonful - lacing - tie (??? my english is really leaving me here, hope you get the idea) <note> can be used to indicate more subtle differentiation (like a "big spoonful", "some leaves" etc). I think this list is both usefully short and complete. The following measures - weight (gram) - volume (litre) - length (metre) can be taken from the measure microformat. I guess measure is already stable enough that it's save to use these terms "experimentally". The measure-element should be optional. That way nobody is forced to select a value from it - it's just a help to facilitate interoperability. * Note Note should stay as an optional value. There are so many ways to define ingredients that it seems usefull enough to fit into the 80/20. And it's a necessary addition to the proposed measurement-values above. * Additional Suggestions - Steps, Ingredient Grouping have both received negative feedback in comments. I could imagine a <grouping> node, together with a <grouping-title> being useful for ingredients as well as for steps (or authors or...). But wouldn't that better be handled by another microformat? XOXO? Or by @section of HTML5? * Additional Suggestions - Diffculty/Notes, Suitability I'd rather not include these. Too diverse in the wild, better handled by tags (at least in the first version). * Scope There seems to be a consensus that this is out of scope. Should be closed as an issue. * Single foodstuffs make no sense imho. Should be closed as an issue. * Menus I would consider this out of scope too. Should be closed as an issue * Multiple Items per Ingredient I don't understand the problem. Since we're talking about free form text entry fields you can easily define one item "salt and sugar" or two items "salt", "sugar". Options can be noted in the <note> field. Okay, hope this helps in advancing the format. Please give feedback! Regards, Thomas [1] http://microformats.org/discuss/mail/microformats-discuss/2008-September/012 461.html [2] http://buzzword.org.uk/cognition/ [3] http://buzzword.org.uk/cognition/uf-plus.html#hrecipe [4] http://microformats.org/wiki/recipe-brainstorming . Thomas Lörtsch Living at Home Multi Media GmbH Redaktion Online .. Stubbenhuk 5 20459 Hamburg ... eMail: [EMAIL PROTECTED] _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
