[uf-new] microformat granularity: currency and measure
andy at pigsonthewing.org.uk
Thu Jul 19 00:23:01 PDT 2007
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:
>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
...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
I don't follow your reasoning there, at all.
>This lack of consensus was confirmed by the poll I had sent. See
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:
>> 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.
Please excuse my brevity - I'm late leaving home.
More information about the microformats-new