Notes on the say-as note

I'm delighted to see that the promised say-as note has finally been  
released ( http://www.w3.org/TR/2005/NOTE-ssml-sayas-20050526/ )

Some input:

Date:

"The same character must be used to delimit all fields in a date string."
At least in Norwegian, dates are commonly written as d/m-y or d/m -y. How  
should these dates be handled?

When a number is both an ordinal and a date (as in Friday the 27.), do you  
recommend marking it up as an ordinal number or a date?

What kind of markup would you suggest for dates like "May 27, 2005" or  
"May 27th, 2005"?


Time:

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

The introduction to the format attribute for time states that "At least  
one separator character must be supported: the colon (:)." However, under  
the heading "Basic tokens of a time string", you find "[Time Field  
Separator] colon (':') , dot ('.'), or empty string ("")" In an  
international perspective, it would make sense that support for all these  
three is required. Fixing this inconsistency in the text should be simple.

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?


Character string:

Have you considered a need/use for a way to group a longer digit string  
into shorter but still complex numbers? E.g. reading 123456 as "twelve  
thirtyfour fiftysix". Could this be achieved in an elegant way with an  
extension to the character format attribute? Currently, two values are  
allowed: "glyphs" and "characters". With a third value, "complex", the  
processor could use the grouping defined in the detail attribute to build  
complex numbers where possible. If detail is undefined, the value of  
"complex" should probably be ignored and fallback to the default value.


General:

The SSML spec says:

"The detail attribute is an optional attribute that indicates the level of  
detail to be read aloud or rendered. Every value of the detail attribute  
must render all of the informational content in the contained text;  
however, specific values for the detail attribute can be used to render  
content that is not usually informational in running text but may be  
important to render for specific purposes. For example, a synthesis  
processor will usually render punctuations through appropriate changes in  
prosody. Setting a higher level of detail may be used to speak  
punctuations explicitly, e.g. for reading out coded part numbers or pieces  
of software code."

However, in the say-as note, detail seems to be used to indicate grouping,  
not level of detail. The way the detail attribute is used in the say-as  
note, it specifies *where* the prosody changes / punctuation reading  
should take place, but not the level of detail it should be spoken with.  
Does the group have any input on this?


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.


-- 
Eira Monstad
Core QA

Received on Saturday, 28 May 2005 08:01:47 UTC