[uf-discuss] Re: Precise Expansion Patterns

[Manu Sporny]

Benjamin Hawkes-Lewis wrote:
>> --------------------------------------------------------------------
>> http://www.w3.org/TR/html401/struct/global.html#adef-title
>>
>> title = text [CS]
>>     This attribute offers advisory information about the element for
>>     which it is set.
>> --------------------------------------------------------------------
>>
>> However, I do agree that "PT2M23S" is stretching the rules a bit.
> 
> Can information that "readers are probably not going to understand" be
> classed as "advisory"?

We could argue it both ways based on how we define "advisory" and the
pattern recognition and cognitive abilities of the general Internet
population. Since we have a potentially better solution on the table,
let's not go down this path yet.

> What I was proposing was this. When all the information required is
> available in the content of the element in Arabic numeral form, and all
> a parser would need to know is what units are being used, we should
> prefer to mark up the units rather than attempt hide an ISO format of
> the same data with the TITLE hack.

Agreed.

> So, to adopt your milliseconds example, we could avoid TITLE and just use:
> 
> <span class="duration"><span class="milliseconds">2</span>
> milliseconds</span>

Sure, we could do that... although, we should be careful to address all
of the problems... we would still need to address some of the
non-standard cases that you outline below.

> We might prefer to specify abbreviations like s and ms, I'm not sure.

If we're going to put "s" and "ms" in @class, then I don't think that
would be a good idea. If we were to, however, place that information in
title... that would be fine, IMHO. To illustrate:

This would be a bad idea:
<span class="duration"><span class="s">3</span> seconds</duration>

This would be acceptable:
<span class="duration"><span class="seconds">3</span> seconds</span>

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

> 1. People might want to use variations on the SI units that cannot be
> expressed with the SI prefixes e.g. 10^26 s.

We can do this if we use hMeasurement:

<span class="duration">10^26 s</span>econds.

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

> 1. Obscure units ("5 chains wide")

Boiling the oceans - we should make them convert it into a more popular
measurement.

> 2. Use of non-Arabic numerals ("III HORA")

Boiling the oceans - make them convert it into a more popular measurement.

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

> 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"? Is displaying "2min 23s",
or "2 minutes 23 seconds" better than displaying "PT2M23S"?

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

-- manu