recipe-issues - Revision history

Tantek: noted issues on hRecipe draft should go on hrecipe-issues.

2008-12-27T22:30:52Z

noted issues on hRecipe draft should go on hrecipe-issues.

← Older revision		Revision as of 22:30, 27 December 2008
Line 1:		Line 1:
	{{TOC-right}}		{{TOC-right}}

	This page reflects externally raised issues about [[recipe]] ~~as well as~~ the discussion that ~~occurs~~ on the microformats-new list (especially [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html here], [http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html here], [http://microformats.org/discuss/mail/microformats-new/2008-June/001629.html here] and [http://microformats.org/discuss/mail/microformats-discuss/2008-September/012509.html 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.		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 [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html here], [http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html here], [http://microformats.org/discuss/mail/microformats-new/2008-June/001629.html here] and [http://microformats.org/discuss/mail/microformats-discuss/2008-September/012509.html 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. — [http://tantek.com/ Tantek]		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. — [http://tantek.com/ Tantek]

ThomasLoertsch: /* closed issues */

2008-12-23T15:44:14Z

closed issues

← Older revision		Revision as of 15:44, 23 December 2008
Line 209:		Line 209:
	</div>		</div>
	</div>		</div>


	<div class="vevent">		<div class="vevent">
	* {{ClosedIssue}} <span class="summary vcard"><span class="dtstart">2008-12-04</span> raised by <span class="fn">[[User:TobyInk\|TobyInk]]</span></span><div class="description">		{{ClosedIssue}} <span class="summary vcard"><code>ingredients</code> should not be required<span class="dtstart">2008-12-04</span> raised by <span class="fn">[[User:TobyInk\|TobyInk]]</span></span><div class="description">
	*# <code>ingredients</code> should not be required. When I proposed this property I intended that it be an ''optional'' wrapper for one or more <code>ingredient</code> properties. Whatsmore, I proposed that an optimisation exist such that any direct child elements of <code>ingredients</code> are assumed to be <code>ingredient</code> 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:		<code>ingredients</code> should not be required. When I proposed this property I intended that it be an ''optional'' wrapper for one or more <code>ingredient</code> properties. Whatsmore, I proposed that an optimisation exist such that any direct child elements of <code>ingredients</code> are assumed to be <code>ingredient</code> 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 <code>ingredients</code> as: "optional. wrapper for 1 or more ingredient elements."		* '''3.2 Schema:''' Define <code>ingredients</code> as: "optional. wrapper for 1 or more ingredient elements."
	# '''3.3.7 ingredients:''' change definition to:		* '''3.3.7 ingredients:''' change definition to:
	#* The element is identified by the class name <code>ingredients</code>.		** The element is identified by the class name <code>ingredients</code>.
	#* A Recipe {{may}} include one or more <code>ingredients</code> elements.		** A Recipe {{may}} include one or more <code>ingredients</code> elements.
	#* The element by definition includes 1 or more <code>ingredient</code> elements. Any direct child elements which are not marked with the <code>ingredient</code> class are assumed to be <code>ingredient</code> elements anyway.		** The element by definition includes 1 or more <code>ingredient</code> elements. Any direct child elements which are not marked with the <code>ingredient</code> class are assumed to be <code>ingredient</code> elements anyway.
	# '''3.3.8 ingredient:''' remove the requirement that it must be the child of an <code>ingredients</code> property.		* '''3.3.8 ingredient:''' remove the requirement that it must be the child of an <code>ingredients</code> property.

	<div class="discussion issues">		<div class="discussion issues">

ThomasLoertsch: This is a minor edit

2008-12-22T19:29:38Z

This is a minor edit

← Older revision		Revision as of 19:29, 22 December 2008
Line 232:		Line 232:
	** I agree with your above proposal (dropping <code>ingredients</code>). 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 <code>ingredient</code>s os fine), but removing it now would not prevent it being revived later. --[[User:BenWard\|BenWard]] 18:52, 9 December 2008 (UTC)		** I agree with your above proposal (dropping <code>ingredients</code>). 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 <code>ingredient</code>s os fine), but removing it now would not prevent it being revived later. --[[User:BenWard\|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 <code>ingredient</code> element for each ingredient when used together with hmeasure. Maybe a native speaker can check and improve that. [[User:ThomasLoertsch \| TomLurge]] 10:16, 11. December 2008 (GMT)		*** 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 <code>ingredient</code> element for each ingredient when used together with hmeasure. Maybe a native speaker can check and improve that. [[User:ThomasLoertsch \| TomLurge]] 10:16, 11. December 2008 (GMT)
	~~</div>~~

	~~</div>~~

	~~<div class="vevent">~~
	~~{{ClosedIssue}} <span class="summary vcard"><span class="dtstart">2008-MM-DD</span> raised by <span class="fn">[[User:ThomasLoertsch\|ThomasLoertsch]]</span></span>~~
	~~<div class="description">~~
	*# Here is the first issue/feedback I have.
	*# Here is the second issue/feedback I have.
	</div>		</div>
	</div>		</div>

ThomasLoertsch: closed issue "`ingredients` should not be required"

2008-12-22T19:28:42Z

closed issue "<code>ingredients</code> should not be required"

@@ Line 7: / Line 7: @@
 == issues ==
 <span id="Issues">Please add new issues</span> to the '''bottom''' of this section by copy and pasting the [[recipe-issues#template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.
@@ Line 236: / Line 210: @@
 </div>
 <div class="vevent">

ThomasLoertsch: /* issues */ ingredient/s issue resolved, hopefully

2008-12-11T10:18:06Z

issues: ingredient/s issue resolved, hopefully

← Older revision		Revision as of 10:18, 11 December 2008
Line 29:		Line 29:
	* 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... [[User:ThomasLoertsch \| TomLurge]] 11:51, 9. December 2008 (GMT) (But see my proposal above)		* 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... [[User:ThomasLoertsch \| TomLurge]] 11:51, 9. December 2008 (GMT) (But see my proposal above)
	** I agree with your above proposal (dropping <code>ingredients</code>). 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 <code>ingredient</code>s os fine), but removing it now would not prevent it being revived later. --[[User:BenWard\|BenWard]] 18:52, 9 December 2008 (UTC)		** I agree with your above proposal (dropping <code>ingredients</code>). 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 <code>ingredient</code>s os fine), but removing it now would not prevent it being revived later. --[[User:BenWard\|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 <code>ingredient</code> element for each ingredient when used together with hmeasure. Maybe a native speaker can check and improve that. [[User:ThomasLoertsch \| TomLurge]] 10:16, 11. December 2008 (GMT)
	</div>		</div>

BenWard: /* issues */ Response regarding ingredients field

2008-12-09T18:53:07Z

issues: Response regarding ingredients field

← Older revision		Revision as of 18:53, 9 December 2008
Line 28:		Line 28:
	** Thinking about it again: how much do we loose if we discard <code>ingredients</code> completly, leaving only <code>ingredient</code>? 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 [[User:ThomasLoertsch \| TomLurge]] 13:15, 9. December 2008 (GMT)		** Thinking about it again: how much do we loose if we discard <code>ingredients</code> completly, leaving only <code>ingredient</code>? 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 [[User:ThomasLoertsch \| 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... [[User:ThomasLoertsch \| TomLurge]] 11:51, 9. December 2008 (GMT) (But see my proposal above)		* 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... [[User:ThomasLoertsch \| TomLurge]] 11:51, 9. December 2008 (GMT) (But see my proposal above)
			** I agree with your above proposal (dropping <code>ingredients</code>). 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 <code>ingredient</code>s os fine), but removing it now would not prevent it being revived later. --[[User:BenWard\|BenWard]] 18:52, 9 December 2008 (UTC)
	</div>		</div>

ThomasLoertsch: /* issues */ typo

2008-12-09T15:19:16Z

issues: typo

← Older revision		Revision as of 15:19, 9 December 2008
Line 6:		Line 6:

	== issues ==		== issues ==
	<span id="Issues">Please add new issues</span> to the '''bottom''' of this section by copy and pasting the [[recipe-issues#~~Template~~\|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.		<span id="Issues">Please add new issues</span> to the '''bottom''' of this section by copy and pasting the [[recipe-issues#template\|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

	<div class="vevent">		<div class="vevent">
Line 35:		Line 35:
	===template===		===template===
	{{issues-format}}		{{issues-format}}


	== resolved issues ==		== resolved issues ==

ThomasLoertsch: added some rather elaborate and IMHO closed points from the brainstorming page

2008-12-09T14:34:35Z

added some rather elaborate and IMHO closed points from the brainstorming page

Show changes

ThomasLoertsch: /* issues */ one more thought about ingredient/s

2008-12-09T13:18:40Z

issues: one more thought about ingredient/s

← Older revision		Revision as of 13:18, 9 December 2008
Line 26:		Line 26:
	** The recipe you gave as an example could be written: <code><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></code>. But certainly <code><ul></code> was the element I had in mind for <code>class="ingredients"</code>. [[User:TobyInk\|TobyInk]] 15:18, 5 December 2008 (UTC)		** The recipe you gave as an example could be written: <code><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></code>. But certainly <code><ul></code> was the element I had in mind for <code>class="ingredients"</code>. [[User:TobyInk\|TobyInk]] 15:18, 5 December 2008 (UTC)
	** Can we make them either/or? Either <code>ingredients</code> or (a list of) <code>ingredient</code>s? [[User:ThomasLoertsch \| TomLurge]] 11:53, 9. December 2008 (GMT)		** Can we make them either/or? Either <code>ingredients</code> or (a list of) <code>ingredient</code>s? [[User:ThomasLoertsch \| TomLurge]] 11:53, 9. December 2008 (GMT)
	* Sorry I messed up your proposal, Toby. I didn't understand it properly. Anyway 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... [[User:ThomasLoertsch \| TomLurge]] 11:51, 9. December 2008 (GMT)		** Thinking about it again: how much do we loose if we discard <code>ingredients</code> completly, leaving only <code>ingredient</code>? 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 - that's not extremely upsetting, if you ask me [[User:ThomasLoertsch \| TomLurge]] 13:15, 9. December 2008 (GMT)
			* Sorry I messed up your proposal, Toby. I didn't understand it properly. Anyway 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... [[User:ThomasLoertsch \| TomLurge]] 11:51, 9. December 2008 (GMT) (But see my proposal above)
	* By the way: I would prefer if these discussions could take place on the mailinglist. That way they would be easier to follow. I would have missed this one if I hadn't planned to document some discussions from the brainstorming-page. At least posting a hint that an issue was opened would be helpful. [[User:ThomasLoertsch \| TomLurge]] 11:54, 9. December 2008 (GMT)		* By the way: I would prefer if these discussions could take place on the mailinglist. That way they would be easier to follow. I would have missed this one if I hadn't planned to document some discussions from the brainstorming-page. At least posting a hint that an issue was opened would be helpful. [[User:ThomasLoertsch \| TomLurge]] 11:54, 9. December 2008 (GMT)
	</div>		</div>

ThomasLoertsch: /* issues */ optionality

2008-12-09T13:05:32Z

issues: optionality

← Older revision		Revision as of 13:05, 9 December 2008
Line 20:		Line 20:
	<div class="discussion issues">		<div class="discussion issues">
	* Agreed complete about not requiring <code>ingredients</code> as a property. I don't think it would fit gracefully with marking up: <kbd>Take some onions, crushed garlic, fry them together, then sprinking liberally with cinnamon for a sweeter onion base.</kbd>. --[[User:BenWard\|BenWard]] 00:47, 5 December 2008 (UTC)		* Agreed complete about not requiring <code>ingredients</code> as a property. I don't think it would fit gracefully with marking up: <kbd>Take some onions, crushed garlic, fry them together, then sprinking liberally with cinnamon for a sweeter onion base.</kbd>. --[[User:BenWard\|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? <code>title</code>, <code>method</code> and <code>ingredients</code> all seem essential to me. [[User:ThomasLoertsch \| TomLurge]] 11:42, 9. December 2008 (GMT)		** 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? <code>title</code>, <code>method</code> and <code>ingredients</code> all seem essential to me. Method has already ben made optional, leaving only title... [[User:ThomasLoertsch \| 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 <code><ul class="ingredients"></code> treat all child <code>li</code> elements as an ingredient makes sense, but generically I disagree. --[[User:BenWard\|BenWard]] 00:47, 5 December 2008 (UTC)		* 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 <code><ul class="ingredients"></code> treat all child <code>li</code> elements as an ingredient makes sense, but generically I disagree. --[[User:BenWard\|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 <code>ingredient</code> treated as a list when on a list element, but singular otherwise? --[[User:BenWard\|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 <code>ingredient</code> treated as a list when on a list element, but singular otherwise? --[[User:BenWard\|BenWard]] 00:47, 5 December 2008 (UTC)

← Older revision		Revision as of 13:18, 9 December 2008
Line 26:		Line 26:
	** The recipe you gave as an example could be written: <code><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></code>. But certainly <code><ul></code> was the element I had in mind for <code>class="ingredients"</code>. [[User:TobyInk\|TobyInk]] 15:18, 5 December 2008 (UTC)		** The recipe you gave as an example could be written: <code><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></code>. But certainly <code><ul></code> was the element I had in mind for <code>class="ingredients"</code>. [[User:TobyInk\|TobyInk]] 15:18, 5 December 2008 (UTC)
	** Can we make them either/or? Either <code>ingredients</code> or (a list of) <code>ingredient</code>s? [[User:ThomasLoertsch \| TomLurge]] 11:53, 9. December 2008 (GMT)		** Can we make them either/or? Either <code>ingredients</code> or (a list of) <code>ingredient</code>s? [[User:ThomasLoertsch \| TomLurge]] 11:53, 9. December 2008 (GMT)
	* Sorry I messed up your proposal, Toby. I didn't understand it properly. Anyway 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... [[User:ThomasLoertsch \| TomLurge]] 11:51, 9. December 2008 (GMT)		** Thinking about it again: how much do we loose if we discard <code>ingredients</code> completly, leaving only <code>ingredient</code>? 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 - that's not extremely upsetting, if you ask me [[User:ThomasLoertsch \| TomLurge]] 13:15, 9. December 2008 (GMT)
			* Sorry I messed up your proposal, Toby. I didn't understand it properly. Anyway 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... [[User:ThomasLoertsch \| TomLurge]] 11:51, 9. December 2008 (GMT) (But see my proposal above)
	* By the way: I would prefer if these discussions could take place on the mailinglist. That way they would be easier to follow. I would have missed this one if I hadn't planned to document some discussions from the brainstorming-page. At least posting a hint that an issue was opened would be helpful. [[User:ThomasLoertsch \| TomLurge]] 11:54, 9. December 2008 (GMT)		* By the way: I would prefer if these discussions could take place on the mailinglist. That way they would be easier to follow. I would have missed this one if I hadn't planned to document some discussions from the brainstorming-page. At least posting a hint that an issue was opened would be helpful. [[User:ThomasLoertsch \| TomLurge]] 11:54, 9. December 2008 (GMT)
	</div>		</div>

← Older revision		Revision as of 13:05, 9 December 2008
Line 20:		Line 20:
	<div class="discussion issues">		<div class="discussion issues">
	* Agreed complete about not requiring <code>ingredients</code> as a property. I don't think it would fit gracefully with marking up: <kbd>Take some onions, crushed garlic, fry them together, then sprinking liberally with cinnamon for a sweeter onion base.</kbd>. --[[User:BenWard\|BenWard]] 00:47, 5 December 2008 (UTC)		* Agreed complete about not requiring <code>ingredients</code> as a property. I don't think it would fit gracefully with marking up: <kbd>Take some onions, crushed garlic, fry them together, then sprinking liberally with cinnamon for a sweeter onion base.</kbd>. --[[User:BenWard\|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? <code>title</code>, <code>method</code> and <code>ingredients</code> all seem essential to me. [[User:ThomasLoertsch \| TomLurge]] 11:42, 9. December 2008 (GMT)		** 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? <code>title</code>, <code>method</code> and <code>ingredients</code> all seem essential to me. Method has already ben made optional, leaving only title... [[User:ThomasLoertsch \| 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 <code><ul class="ingredients"></code> treat all child <code>li</code> elements as an ingredient makes sense, but generically I disagree. --[[User:BenWard\|BenWard]] 00:47, 5 December 2008 (UTC)		* 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 <code><ul class="ingredients"></code> treat all child <code>li</code> elements as an ingredient makes sense, but generically I disagree. --[[User:BenWard\|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 <code>ingredient</code> treated as a list when on a list element, but singular otherwise? --[[User:BenWard\|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 <code>ingredient</code> treated as a list when on a list element, but singular otherwise? --[[User:BenWard\|BenWard]] 00:47, 5 December 2008 (UTC)