- From: <frank.scahill@bt.com>
- Date: Thu, 12 Apr 2001 11:42:08 +0100
- To: alex.monaghan@aculab.com, www-voice@w3.org
Alex, Thanks for your comments, here are some responses >2.1 - some of the issues which this document treats as unresolved (e.g. pronunciation alphabets and suprasegmental information) have already been decided for the Speech Synthesis Mark-up spec: interoperability presumably requires that these documents concur. Yes these documents will concur. Both SSML and GrammarML include some aspects of pronunciation specification that predate this work on a standard lexicon format. The development of the pronunciation lexicon markup will build on what has already been done but may ultimately result in changes to the SSML and GrammarML. > 4.3 - syntactic category is only a "should have", but if this is absent i don't see how the treatment of homographs (4.6, a "must have") can be achieved. The reason syntactic category is only a "should have" is that it may prove difficult to standardise the set of allowable values for this category, the more loosely defined "information field" (R4.4) was made a "must have" to then provide a way in which to distinguish homographs but not necessarily via a standardised set of categories. This may lead to vendor specific interpretations of what is in the information field, clearly this is less than ideal but the priorities were set according to what was thought achievable for a first draft >5.10 - can we please distinguish between acronyms (those items, such as DEC or NASA, which are made up of capital letters but are pronounced as a word) and other sequences of capital letters such as all the examples given in this draft This requirement was intended to mean a short hand pronunciation mechanism for acronyms that could be specified using other graphemes. Examples such as NASA would need to be represented using the full blown pronunciation mechanism, however examples such as BT could as represented as "b t" ( or even "bee tea") and rely as you say on their being an existing pronunciation for each letter/word. But a mechanism is still required to indicate "BT", "bt" and "b t" are equivalent, as you point out in your examples attempting to rely on some standard rules for handling of case is inadequate. >6.7 - WHY?! The requirements ask for vendor specific alphabets in addition to the standard pronunciation alphabets. The issue of whether vendors must support the standard pronunciation alphabets will be addressed by the compliance statement in the specification itself, which has yet to be defined. The intention is that the requirements cover the case where application developers wish to use a standard alphabet for content portability or where application developers wish to use a vendor specific alphabet for legacy or other reasons. Regards Frank
Received on Thursday, 12 April 2001 07:18:10 UTC