hrecipe-issues
<entry-title>hRecipe issues</entry-title>
This page reflects issues raised about the hRecipe microformat.
Past issues captured during brainstorming towards hRecipe can be found in recipe-issues.
Some issues may be 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 (and recipe-issues) carefully 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
If you have general feedback on hRecipe (positive/neutral/negative) please add to hrecipe-feedback rather than this document.
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.
- open issue! 2008-12-27 raised by Tantek Çelik
- Too many properties. From reviewing the recipe-examples, it does not appear that the schema implied by the examples justify the number of properties in hRecipe, especially for a first draft. microformats should start as small as possible (even smaller), and in this regard I believe several improvements could be made. There is one obvious example of recipe-title vs recipe-summary, but it looks like there may be more. Would appreciate feedback from folks who add hRecipe to the recipes on the web regarding which properties they ended up not using.
- proposed resolution: Drop "recipe-title". In reviewing the examples, few (if any?) include *both* a title and a summary, and in practice the semantics of usage in the context of recipes appears to be virtually indistinguishable. Therefore we don't need both, and following in the pattern provided by hCalendar (which got it from RFC2445), we should keep the more generic concept of a "summary" and drop the concept of "title" from hRecipe.
- Unnecessary recipe prefixing of summary property. Note: this is a re-opening of an issue from recipe-issues. The usage of summary in recipes appears to be very similar to that used for events. Rephrased, insufficient (if any?) evidence has been provided that summary means anything "special" enough (distinguishing it from the generic term "summary" as used in microformats) in the context of recipes to merit prefixing and thus a new property.
- proposed resolution: Re-use generic "summary" property rather than introducing a recipe microformat scoped "recipe-summary" property.
- author is re-used from hAtom not hCard. minor issue. the "author" property is actually re-used from hAtom rather than hCard - hCard has no such property.
- preparation-time could re-use duration instead - it appears that the "preparation-time" semantic basically means the "duration" of the recipe, and thus could re-use that property from hCalendar rather than introducing a new property name.
- proposed resolution: change "preparation-time" to "duration" and note re-use from hCalendar - or at least document how preparation-time is a different enough semantic from "duration" to justify the introduction of a new term.
- One difference is that hCalendar duration is a singular property whereas hRecipe's preparation-time is plural. Also, preparation-time will often (typically) use value+note subproperties, while duration will usually be an ISO 8601 duration. TobyInk 20:32, 29 December 2008 (UTC)
- Also, if an hRecipe is nested within an hCalendar (e.g. a vtodo containing an hRecipe within the description), we probably wouldn't want naïve hCalendar parsers using an hRecipe's cooking time as the entire duration of the hCalendar component. TobyInk 20:32, 29 December 2008 (UTC)
- Too many properties. From reviewing the recipe-examples, it does not appear that the schema implied by the examples justify the number of properties in hRecipe, especially for a first draft. microformats should start as small as possible (even smaller), and in this regard I believe several improvements could be made. There is one obvious example of recipe-title vs recipe-summary, but it looks like there may be more. Would appreciate feedback from folks who add hRecipe to the recipes on the web regarding which properties they ended up not using.
resolved issues
- none currently
closed issues
- none currently
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>
- hRecipe
- hRecipe feedback for general feedback on hRecipe.
- recipe microformat effort development
- recipe-issues past issues raised and resolved during recipe-brainstorming towards the development of hRecipe.