[uf-new] microformat granularity: currency and measure

[Andy Mabbett]

In message <469E8812.7090003 at brixlogic.com>, Guillaume Lebleu 
<gl at brixlogic.com> writes

>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

...for some value of "rare". I have provided evidence of widespread use 
f historical monetary values. "Five dollars" today does not have the 
same value as "five dollars" did a hundred, or even twenty, years ago.

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

I don't follow your reasoning there, at all.

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

I don't believe that that poll has any value; not least because only 
nine people participated.

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

That's  hypothetical argument backed with no evidence.

>> 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 don't see what you're saying here - please clarify.

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


Sure.

Please excuse my brevity - I'm late leaving home.

-- 
Andy Mabbett