[uf-discuss] Re: Precise Expansion Patterns

[Benjamin Hawkes-Lewis]

Manu Sporny wrote:
> If we're going to put "s" and "ms" in @class, then I don't think that
> would be a good idea.

Can you elaborate why?

One argument might be that consistency of naming across all units can 
help authors remember syntax.

But my thinking in suggesting symbols as an exception for SI units was 
that symbols are not subject to spelling variations. It's always "m" but 
may be "metre" or "meter" for example:

http://en.wikipedia.org/wiki/SI

In other words, I think enforcing symbols for SI units would produce 
fewer errors by authors.

> Or if we wanted to use the hMeasurement approach:
> <span class="duration" title="3s">three seconds</span>
> <span class="duration" title="2min 3s">two minutes, three
>                                          seconds</span>
> <span class="duration" title="2y 35h">two years, 35 hours</span>
> <span class="duration" title="3s">three seconds</span>
> 
>> Obviously, if this principle were to be extended to other sorts of
>> measurements, it could get more complicated for two reasons:
> 
> Take a look at the hMeasurement strawman... there's been a great deal of
> thought put into the issues that you describe:
> 
> http://microformats.org/wiki/measure-brainstorming#Straw_man

/If/ it does not over-complicate the task for parsers or authors, I have 
no objection to the contents of elements being parsed as values. But I 
suspect this would only help in a small subset of cases (English content 
where digits and common units are supplied).

>> 2. People might want to use non-SI, non-global units like inches and
>> quarts.
> 
> Then they will need to convert it to SI units:
> 
> <span class="weight" title="95.2543977 kg">15 stones</span>
> 
>> Now, it might be that we could adapt the principle to serve in some of
>> those situations too:
>>
>> 1. Perhaps we could allow class names like "seconds/10^26" (it's ugly
>> but legible and conforming).
> 
> We can already do this in hMeasurement:
> 
> <span class="duration" title="10^26s">10^26 seconds</span>
> 
> Or, alternatively they could convert it to another representation format:
> 
> <span class="duration" title="100Ys">10^26 seconds</span>

>> 2. Perhaps we could think about specifying class names for widely-used,
>> non-SI units like inches.
> 
> Like this (in the current hMeasurement proposal):
> 
> <span class="length" title="4ft 4in">four feet, four inches</span >

Yes, my problem with this is that I think TITLE is being misused.

>> 3. Use of words instead of digits ("three seconds long")
> 
> I think addressing this was outlined above.
> 
>> 4. Fuzzy representations where not all the information required is
>> implicit in the human-friendly content ("about three miles")
> 
> There is room for error metrics in hMeasurement too, although, it hasn't
> been worked out quite how we do that.

I'm not talking about a margin of error in the measurement, but about a 
loose human representation used in extended prose being annotated with a 
more precise representation purely for machine consumption. For example, 
we know it's exactly 3.214 miles and want microformat parsers to know 
that, but we say "about three miles" in the prose.

>> For these cases, we would /still/ need an expansion pattern. I wasn't
>> particularly thinking of the expansion pattern you suggest, since it's
>> still attempting to put tortured data-showing requirements over the
>> needs of human end-users.
> 
> Do SI measurements constitute "tortured data"?

It's not the data I was calling "tortured". I was referring to the 
impossibility of going in two directions simultaneously:

1. Microformat data must be human-readable and visible to be maintained.

2. Some microformat data is so human-hostile we need to allow it to be 
replaced by human-friendly content.

Hiding data in a tooltip is a sort of half-way house that doesn't really 
satisfy either of these principles.

> Is displaying "2min 23s",
> or "2 minutes 23 seconds" better than displaying "PT2M23S"?

Not really. "min", "minutes" and "seconds" might be just as 
incomprehensible when content is in a non-English language or a 
non-Latin script.

>> The point of my suggestion is to reduce the number of cases where we
>> need an expansion pattern, since expansion patterns are proving
>> problematic.
> 
> Let's address the actual problem of precise expansion patterns for
> measurements.
> 
> So we could do one of the following:
> 
> 1. Use hMeasurement and add "h for hours" and "y for years".
> 2. Define "second", "minute", "hour", "year" classes.
> 3. Create "second", "minute", "hour", and "year" aliases in to the
>    hMeasurement units "s", "min", "h", and "y", respectively. Use
>    hMeasurement.
> 
> I suggest doing the 3rd thing, which would give us all of the following,
> valid, markup:
> 
> <span class="duration">2 minutes 23 seconds</span>
> <span class="duration" title="2 minutes 23 seconds">2:23</span>
> <span class="duration" title="2 min 23 s">2 minutes, 23 seconds</span>
> <span class="duration" title="2 min 23 s">2:23</span>
> 
> This approach is more of a measurement design-pattern, but solves the
> accessibility and usability issues surrounding using ISO8601 and a
> variety of the other ISO formats for measurement.

Defining "s", "minutes", "hours", and "years" classes would handle all 
four cases above without detracting from the end-user experience with 
unwarranted, potentially confusing, TITLE attributes.

--
Benjamin Hawkes-Lewis