[uf-new] Recipe

[Andy Mabbett]

In message <05A70B8D-ACF3-4965-80F9-848E86BFD345 at ben-ward.co.uk>, Ben 
Ward <lists at ben-ward.co.uk> writes

>> I maintain that we should build the re-usable microformats 
>>(measurement,
>> currency, citation) first; then those that will use them.
>
>I completely disagree with this.

Then we run the risk of allowing the "higher level" microformats to 
de-facto define the "lower -level", (As hAudio is doing with currency); 
effectively outside the "process".

>A Recipe format can be useful and improve publishing without explicit 
>mark-up for measurements and citations.

Useful to a degree, but less so than with semantic markup for those 
items.

> We should not delay  development of a format that shows so much 
>existing publishing and  interest from publishers because of missing 
>compound microformats  which are not attracting the same levels of 
>interest.

Then we're in danger of letting populism override good practise.

>In the case of Recipe, I maintain that both quantity and ‘source’ 
>would be usefully represented as strings. ‘10g’, ‘One handful’, 
>‘Three Tablespoons‘ is workable and useful. Similarly, <span 
>class="source">Real Food by Nigel Slater</span> is perfectly useful  in 
>that form.

Again, useful to a degree, but less so than with semantic markup within 
that span and the strings.

>I think it's a reality of the way in which development currently  moves 
>in this community; that development and interest comes in  waves. It 
>means to me that forcing dependencies on undeveloped  compound 
>microformats, which currently have little interest and  backing, will 
>in effect kill development of this format which people  are interested in.

Or we could just encourage more participation in developing those 
microformats.

Why do you think there is little apparent interest, given that such data 
types vastly out number recipes, audio downloads, listings or whatever? 
Are people doing the "fun" stuff and neglecting the "housework"?

I think we could, if we put our collective mines to it, have first-draft 
currency (even if only for current, decimal currencies) and measurement 
(even if only for metric values) microformat in a few weeks (and, again, 
doing so before Firefox 3 goes live would be A Good Thing [TM]). Surely 
no-one can deny the evidence that such data is widely published?

>I think it is much more productive to accept that Recipe is capable  of 
>representing quantities and sources well enough with strings, and  know 
>that future, more precise microformats (or other technologies developed 
>elsewhere, such as MathML) _may_ come in the future that  can enhance 
>the work we're doing now.

Then we have to revise the Recipe spec, and update all the parsers...

>>>> Measurement System (U.S., Imperial etc)
>>>
>>> I don't see this being useful. Recipes do not use consistent
>>> measurements: There are combinations of metric weights and 
>>>approximate
>>> ‘handfuls’ and ‘pinches’. Some recipes publish  both metric and
>>> imperial measurements alongside each other.
>>
>> In that case, perhaps only one system should be microformatted, to 
>>avoid
>> confusing parsers?
>
>That would work for situations where two different measurement  formats 
>are placed next to a single ingredient, but does not handle  different 
>measurements being used in the same recipe for single  ingredients. I'm 
>not quite sure which issue you were addressing there.

I meant the former ("add 125g or 4oz of butter").

>> Whether an ingredients is optional or required is important (again,
>> consider the "ingredients to hand" use case).
>
>Agreed, that's a very good use-case. Needs to be included in a 
>language-agnostic manner but writing ‘3 sprigs of parsley (optional)’ 
>is familiar. I would think that ‘Required’ is implied by the 
>absence of ‘Optional’.

Agreed.

-- 
Andy Mabbett