Re: Notes on the say-as note

On Fri, 27 May 2005 15:23:57 +0200, Eira Monstad <eiram@opera.com> wrote:


> Some input:
...
> Time:
>
> Hours are restricted to 0-23. In Norwegian, and probably other languages  
> as well, 24 is often used instead of 00.

agreed. I have seen this in various places.

Examples would be something like

closes at <say-as interpret-as="time" format="h">24h</say-as> monday to  
thursday.

I think this is more natural than

closes at <say-as interpret-as="time" format="h">00h</say-as> monday to  
thursday.

In either case they mean midnight, but there is a question of which end of  
a given day the particular midnight in question occurs. (This is  
complicated by the lack of a date-time value - see my final comment). The  
distinction is often quite subtle, and (I assert) the reason why the use  
of 24 as a nominally redundant time specification is in fact valuable.  
Although this is an edge case it is a remarkably common one - in the  
english speaking world where the twelve hour clock is more common we still  
say the analagous 12 o' clock meaning midnight, and not 00:00. And we  
usually qualify it fairly carefully.

I think Eira's suggestion here is a good one. I am also interested to know  
what you expect people to use for midnight in a 12 hour system.

> The list of allowed qualifiers is very specific. However, in some  
> languages the qualifiers are translated and thus will not conform to the  
> list. Additionally, especially in older texts, a.m. and p.m. are often  
> mispunctuated, missing the last dot. Some languages' ortographic  
> conventions may even allow omitting the trailing dot in abbreviations.  
> How should conforming synthesis processors be expected to handle these  
> cases?

These should, IMHO, be noted.

In the time section it says "to avoid complications between mistaking a  
time qualifier for a time zone, the time zones are not included in the  
say-as time format. If a time zone is to be specified, it should be done  
outside the say-as element". This means that in order to avoid confusion  
with a very few common terms in a limited context you should search for  
extra information in free text.

That seems a worse solution, since it allows for time zone identifiers to  
be confused with whatever kind of free text content follows the time,  
rather than dealing with the much more limited case of time qualifiers.

> And one last question: Have you considered the need for other  
> categories, such as fractions? I'd be interested in hearing about how  
> you decided what to put on the list and what not to put on it.

In particular I am curious about why there is no date/time. For a  
specification that apparently aims to note the inherent semantics in the  
kind of semi-structured text that people actually speak or write, it seems  
like an obivous thing to be able to identify, yet is unsupported.  
Date-time therefore relies entirely on guessing by proximity or context,  
when many commen ways of specifying it are relatively straightforward  
allowing for a bit of "verbal putty" in between the two.

cheers

Chaals

-- 
Charles McCathieNevile                              chaals@opera.com
          hablo español - je parle français - jeg lærer norsk
   Here's one we prepared earlier:   http://www.opera.com/download

Received on Wednesday, 1 June 2005 13:28:53 UTC