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
_______________________________________________
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Reply via email to