[uf-new] Recipe

[Ben Ward]

On 28 Sep 2007, at 13:03, Andy Mabbett wrote:

> 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".

There's an important line to draw. Taking the case of Price in  
Listing, ‘Quantity’ in Recipe and ‘Source’ in Recipe: In each case  
the format would effectively be saying ‘this far, but no further’.  
Declaring that ‘This is the price, but the content within is  
undefined’. The format of the data itself is *not* defined by Listing  
or Recipe. And it's important that they not spread into doing so.

I mean: If Listing was to not only specify a place for ‘price’ but  
also to identify the ‘currency’ of that price, that would be wrong in  
my view and would be encroaching on work that I totally agree should  
be done on a dedicated format. Or at least, the ‘price’ part of  
Listing development should then be treated developing a compound  
microformat. However, what it actually does is just indicate the  
price, as a whole, such that a future  currency format would ‘drop  
right in’. It imposes nothing at all on a currency format; it's just  
the container.

The same is true of Quantity and Source in our current recipe.  
Identifying the place for the field does not impose anything on on  
potential compound formats to expand them.

If we develop Measurement and Currency, they drop in. You go from  
<span class="quantity">30g</span> to <span class="quantity  
hMeasurement"><span class="value">30</span><abbr class="unit"  
title="gram">g</abbr></span>.

I completely agree with your sentiment that we should not do anything  
that would bypass proper development of the compound formats.  
Totally. But in these cases, we're only specifying what ends up being  
the container of such a format.

>> 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.

Which is a motivation to create citation and measurement formats for  
sure, but as with what I say above, they can be independent.

>> 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.

We shouldn't allow that to happen. We a format depends on the detail  
of a compound format I agree it should be developed separately.

> 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"?

Not sure to be honest. Interest is going to be individual. I make no  
secret of the fact that right now my participation happens on a whim.  
I don't have regular free time to commit so I offer what I can.  
Different topic which would be interesting to find out more about,  
since the sporadic nature of our development effort isn't perhaps  
optimal. If we can establish what makes things happen in surges, it  
would of course be good to improve and smooth out the process.

> 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'm all for trying to revive development of the other formats.  
Definitely a Good Thing. But I don't think it should be blocker on  
Recipe in the event that it developed sooner.

Ben