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

[Andy Mabbett]

On Fri, October 5, 2007 14:57, Chris Newell wrote:

>> 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.

*If*; For some value of "hard to parse".

This process is about making sure that's not the case.

> 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>

That would be:

<abbr class="hmeasure" title="2m2">2m<sup>2</sup></abbr>

using "m2", or whatever is that standard for representing square-metres.

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

We can't.

>>> - 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.

Then your comment appears redundant.

>>> - 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:
> ....."

"parsers" not "users".

-- 
Andy Mabbett
** via webmail **