In message <[EMAIL PROTECTED]>, Guillaume Lebleu
<[EMAIL PROTECTED]> 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
_______________________________________________
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new
