[uf-new] microformat granularity: currency and measure (re-send)

[Guillaume Lebleu]

Andy Mabbett wrote:
> In the case of currency, I think we should polish and publish:
>
>   
> <http://microformats.org/wiki/currency-brainstorming#Straw_man_proposal>
I had came up with http://microformats.org/wiki/currency-proposal as a 
cleaned up version of the straw man proposal. I believe the only 
difference between the straw man proposal and this cleaned up version 
was that I removed the date and the symbol class names.

The reason for the date removal was due to the lack of strong consensus 
on the value of the "date" class name for two reasons:

    * Occurrence of dated money amounts is judged rare: See
      http://microformats.org/discuss/mail/microformats-discuss/2006-September/005802.html
    * Date is not a property of the money amount, but of a currency
      rate: See
      http://microformats.org/discuss/mail/microformats-discuss/2006-September/005927.html

This lack of consensus was confirmed by the poll I had sent. See 
results: 
http://www.vizu.com/res/Business/Technology/microformats/currency/poll-results.html?n=15067&formBean=com.productengine.vizu.model.poll.PollNonvoters%401aca8cc

"symbol" suffered the same lack of consensus, possibly due to a lack of 
understanding of the benefits. Maybe a more detailed explanation of the 
benefits of such a class name would be worth writing. If I understood 
correctly, the main value would be for a user agent to be able to 
replace it with the symbol of the currency that the amount is converted 
to. If that's the case, I would argue that a user agent may not want to 
replace the content, since it may fool the user into believing that 
these amounts are guaranteed by the publisher/merchant, where in fact, 
they would be mere estimates, which may differ from the actual rate 
charged by the merchant or the financial intermediary.

Let me know if I missed something.

>
> In the case of measurement, we can use your examples:
>
>   <http://microformats.org/wiki/measure-brainstorming#Guillaume_Lebleu>
>
> as a straw-man, but the chief unresolved issue is what to do about the 
> plethora of non-SI units, and which we should include.
>
I think Bogdan and Emil came with some solutions using composition of SI 
units and scaling, in line with some of the practices I had identified 
(ex. XBRL). This could work for unusual units, when coded shortcurts for 
common compositions (ex. square meters) are not available from standard 
bodies such ISO or UNECE. Using standard codes for common compositions 
of units and allowing custom compositions for unusual units should 
hopefully be in line with a "simple things simple, complex things 
possible" principle.

I suggest that I come up with a draft proposal based on the current 
suggestions that we can start the discussion from.

Guillaume