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

[Paul Wilkins]

On Dec 15, 2007 8:21 AM, Ben Ward <lists at ben-ward.co.uk> wrote:
> 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 agree, on the proviso that we take into account redefinitions from
HTML5 and XHTML 2.0, for in several cases they have provided a greater
understanding of the intention than the earlier HTML4 spec thought to
provide.

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

I have to agree here.

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

The hAudio time should be denoted in seconds. If 3:23 is given it's to
be seen as three minutes and twenty two seconds. If hours are needed
it should be 1:3:23 (0 prefix optional) to denote 1 hour three minutes
and twenty two seconds.

This way the hAudio standard can work without needing to modify the
text, the abbr pattern isn't required and everybody can go home and
sleep restfully for the night.

> Thank you,

I concur.

-- 
Paul Wilkins