Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes)

[Ben Ward]

On 14 Dec 2007, at 14:06, Benjamin Hawkes-Lewis wrote:
> I think all of the following would be misuses of ABBR and TITLE:
>
> | Combien d'œufs ai-je vendre? J'ai vendu <abbr title="quarante-cinq">
> | 45</abbr> aujourd'hui.
>
> | Combien d'œufs ai-je vendre? J'ai vendu <abbr title="45
> | œufs">45</abbr> aujourd'hui.
>
> | Combien d'œufs ai-je vendre? J'ai vendu <abbr title="45
> | eggs">45</abbr> aujourd'hui.
>
> | Combien d'œufs ai-je vendre? J'ai vendu <abbr title="30+15">
> | 45</abbr> aujourd'hui.
>
> | Combien d'œufs ai-je vendre? J'ai vendu <abbr
> | title="sales:a464Z37;q45dt2007122007">45</abbr>
> | aujourd'hui.
>
> "16:03" could be re-expressed as "3 minutes past 4pm". It's not  
> obvious that "16:03" is an /abbreviation/ of "3 minutes past 4pm".  
> For one thing, the 12-hour clock is not an expansion of the 24-hour  
> clock: they are equivalents. For another thing, I'd say it's more  
> of a common symbolic representation. "4" wouldn't normally be  
> called an abbreviation of "four": it's just a symbol. (Some symbols  
> are also arguably abbreviations, at least in origin, like cm, but  
> this wouldn't generally be said of 4.)

Agreed. I'll repost something I put into the GEO thread last week.  
It's quoting directly from the HTML4 specification. This doesn't  
actually need to have any concern with accessibility, or assistive  
technology tools. Frankly, the difficulty in getting solid tests from  
such tools makes that line of argument less attractive in itself. But  
what has to be a fundamental baseline in our implementation of  
optimisation patterns in microformats is the HTML specification we  
are building on top of. We *do not* have the authority to disobey the  
spec. We may interpret it _more strictly_ perhaps, but we may not  
_relax_ any of the definitions it provides. Otherwise we have no leg  
to stand on regarding the effect our code has on _any_ consuming tool.

I said this:
> > “The content of the ABBR and ACRONYM elements specifies the  
> abbreviated expression itself, as it
> > would normally appear in running text. The title attribute of  
> these elements may be used to provide
> > the full or expanded form of the expression.”
>

For emphasis again:
> > “as it would normally appear in running text.”

I know there are lots of concerns about the effect of the ABBR  
pattern on assistive technology tools. I know there are reports of  
problems and negative impact on user experience. Getting evidence is  
proving hard because the sheer number of variables in a real  
assistive technology user's configuration is much larger than for  
visual desktop browsers. It actually doesn't matter, because the ABBR  
pattern is being mis-used at a more fundamental level.

First, some happy news. Here's the ABBR pattern being used validly  
and correctly in hCard:

> <abbr class="country" title="United Kingdom">UK</abbr>


There is an argument that the ISO timestamp format is an expansion  
of  a human formatted date (‘Thursday, September 23rd’). I personally  
disagree, but it was accepted at the time. But since then, the use of  
the pattern has expanded without the same concern for the HTML spec.

‘One hour ago’ is NOT ever an abbreviation of a timestamp. ‘last  
week’ IS NOT an abbreviation of a timestamp. ‘London’ IS NOT an  
abbreviation of a set of co-ordinates and ‘3:23’ IS NOT an  
abbreviation of the string ‘PT3M23S’ (hAudio). In all of those cases  
they are ‘alternative representations’, or ‘expansions’ or perhaps  
‘precisions’. They ARE NOT abbreviations and they are in clear  
conflict with the HTML spec which states the TITLE attribute of ABBR  
must be ‘the abbreviated expression itself, as it would normally  
appear in running text’. Sorry, but the ball got dropped on this, and  
people have been treating the ABBR-pattern as a handy pattern first  
and HTML second. That is the wrong way around.

So we have a problem. We now have multiple use cases where it is  
necessary for publishers to include precise machine data alongside  
human legible descriptions. They are rarely real abbreviations.

I am going to ask that we better define the problem. That we follow  
up the demand for a better pattern (regardless of whether your  
personal motivation is following the spec or assistive technology).  
I'd like to ask that people stop jumping straight in with ideas for  
alternative mark-up, ways of kludging the existing practice into  
different elements or attributes. Follow the process. We need to  
fully define the problem: We need a list of which microformat  
properties _require_ the facility for precise representations. They  
don't all need it, maybe we just need something that certain  
properties may opt into, rather than something that covers all  
microformats properties. That's what we need to determine. From  
there, we can move on how to integrate the data back into mark-up.

Thank you,

Ben