[uf-new] microformat granularity: currency and measure
Guillaume Lebleu
gl at brixlogic.com
Wed Jul 18 14:37:22 PDT 2007
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-new/attachments/20070718/1aa1c780/attachment-0001.html
More information about the microformats-new
mailing list