[uf-new] Measurement brainstorming (was: Measure & currency)

Chris Newell chris.newell at rd.bbc.co.uk
Fri Oct 5 06:57:00 PDT 2007

At 12:44 05/10/2007, you wrote:
On Fri, October 5, 2007 11:20, Chris Newell wrote:
>>> a new "measurement" microformat straw-man on the wiki:
>>> <http://microformats.org/wiki/measure-brainstorming#Straw_man>
>> I guess you may have been through this but my first thought is why not
>> separate unit-code and value?
>Please read Taylor Cowan's original comments:
>> The reasoning being:
>> - Programmers hate parsing strings (particularly if you have to deal with
>> a number of different formats and field orders) and parsing strings is
>> notorious for causing implementation interoperability problems.
>Microformats put the burden, where possible, on parsers, not publishers,
>in order to make life as easy as possible for publishers.

Agreed, but this is a balance. If it's hard to parse you'll get buggy implementations.

For "currency" the parsing is not too bad because the unit-code is restricted to ISO currency codes (a fixed set of three letter codes).

However, for "measure" (where the unit-codes encompass all SI permutations etc) parsing the string to separate the value from the unit-code gets more tricky and potentially ambiguous. For example:

   <span class="hmeasure">2m<sup>2</sup></span>

I guess this wouldn't be too bad if we can state that numbers within unit-codes are always in <sup> tags.

>> - Users may want to style the unit-code differently from the numerical
>> value and the separation would make this easier.
>They are not prevented from doing so by the current proposal.

I didn't say they were.

>> - Users wouldn't have to remember rules about the format of the string.
>What rules?

The Strawman proposal states "where parsers must accept the formats: ....."

Chris Newell
Lead Technologist 
BBC Research

More information about the microformats-new mailing list