The following are real-world examples and brainstorming for marking up currency.
The problem: how to explicitly specify a) that a figure/number relates to money; b) the currency of a stated figure; and c) the period in which that figure was current.
- The currency sign cannot be used reliably since the same sign (or symbol) may represent more than one currency. eg. $ is used for many different dollars (USD, AUD, CAD...) and even other units like pesos.
- The language of the page is not sufficient to define the currency of prices in the page:
- More than one currency may be used by people who speak the same language.
- The page may be written in one language and still quote prices/figures in a different country's currency.
- Even if a country can be identified, more than one currency may be used in that country.
Converting currency figures is a reasonably easy problem to solve as indicated by the #Existing_Practices. However many automated conversion tools must make assumptions about the original figure's currency -- e.g. assuming a USD for all uses of $, or British Pounds for £ (which is also sometimes used to denote Lira).
I wish to expand on one of the points mentioned above: there might be two or more currencies in the same country: e.g. in Romania
- ROL - Romanian Lei [being phased out]
- RON - Romanian New Lei
- after Romania joins the EU, the RON will be replaced by Euro, too (not imediately, probably in 2-3 years)
Although the three letter code is different in this case, the currency is often given as Lei. There are other countries, where similar examples exist/existed. The two currencies might have an identical name, yet they have 2 very different meanings. Usually there is a difference of 3-4 orders of magnitude between the old currency and the new currency. discoleo
"Amounts" in arbitrary units is a bit harder and necessary for several applications.
For example, consider the work that has been done on a recipe microformat.
Though we haven't reached this problem yet in the research, I can see it coming:
Say you wanted to create a "shopping list" application which you could tell which recipes you wanted to cook, and have it automatically total up all the various amounts of ingredients and give you the net amount of stuff you wanted to pick up.
It would need to be able to determine precise amounts/units of each ingredient. This might turn out to be like the currency problem, or it might be more complex, given the variety of units used in recipes, English vs. metric etc. That's a case that might need a microformat. We need more research and analysis to really justify it, but I can see it within the realm of probable possibility.
Use of currency amounts in tables
Representing currency amounts in a table format is very common. For instance, see Google Financials.
In this table representation, it does not make sense to provide the currency information for each cell. Instead, it should be provided once at the table, thead, tr, or th, level, and then a td may override the default value. This is very similar to the common practice of indicating the currency and formatting in plain english: "Numbers in thousands of dollars" in the table title/subtitle or legend.
The microformat for currency amounts should provide a way to represent a default currency for all children of a table, thead, tr, or th nodes. The currency symbol/abbreviation should be optional in for elements defined as containing currency values/amounts, if a default currency has been defined in one of the ancestor elements.
- Ben Buchanan (proponent)
- Arve Bersvendsen
- Tantek Çelik
- Steve Ganz
- Charles Iliya Krempeaux
- Andy Mabbett (2nd proponent)
- Ciaran McNulty
- Mike Stickel
- Ben Ward
- Guillaume Lebleu
Links to public web pages, either popular or insightful
The associated XML Schema seems to suggest an Amount element, followed by a fixed Currency element of "GBP".
2.1 US cents/2.4 CAN cents per minute
(on the Web page)