[uf-new] Measurement brainstorming (was: Measure &
currency)
Chris Newell
chris.newell at rd.bbc.co.uk
Fri Oct 5 06:57:00 PDT 2007
Andy,
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:
>
><http://microformats.org/discuss/mail/microformats-new/2007-September/000915.html>
>
>> 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
_______________________
Chris Newell
Lead Technologist
BBC Research
More information about the microformats-new
mailing list