SSML 1.0 say-as attribute values

Abstract

The say-as element in SSML 1.0 is considered one of the most useful elements of the language. However, SSML 1.0 does not define the values of the attributes of this element. This Note provides definitions for these attributes that cover many of the most common use cases for the say-as element.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is the 26 May 2005 W3C Working Group Note of "SSML 1.0 say-as attribute values". There is general agreement within the Working Group that the attribute values defined here are the most critical ones and are useful as defined; however, there is interest both in designing additional definitions and in alternate definitions to some of those provided. Although the content may of course change before being introduced into a Recommendation-track document, the Working Group believes that the publication of this Note at this time may assist vendors in moving towards a common implementation rather than away.

The public is invited to send comments to the Working Group's public mailing list www-voice@w3.org (archive). See W3C mailing list and archive usage guidelines. Comments received may be taken into consideration if the material in this Note is used in some form in the creation of a Recommendation-track document.

This document has been produced as part of the W3C Voice Browser Activity, following the procedures set out for the W3C Process. The authors of this document are members of the Voice Browser Working Group (W3C Members only).

This document was produced under the 5 February 2004 W3C Patent Policy. The Working Group maintains a public list of patent disclosures relevant to this document; that page also includes instructions for disclosing [and excluding] a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.

Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

0. Table of Contents

• 1. Introduction
• 2. Extension mechanism
• 3. Defined interpret-as values
  • 3.1 Date
  • 3.2 Time
  • 3.3 Telephone number
  • 3.4 Character string
  • 3.5 Cardinal number
  • 3.6 Ordinal number
• 4. References
• 5. Acknowledgments

1. Introduction

The Speech Synthesis Markup Language (SSML) [SSML] provides a variety of markup elements to direct the behavior of a speech synthesizer in its processing of text to be spoken. One of the features in this language is the say-as element [SSML §3.1.8], which provides for semantic tagging of content to assist the processor in disambiguation of ambiguous input or to simplify authoring in common cases where the processor knows how to perform the conversion of certain types of content into orthographic text for the target language. However, SSML 1.0 does not define the values of the attributes of this element, leaving open the questions of what standard content types might exist and how extensions beyond those types might be introduced. This Note fills in the gap by

1. defining how standard content types are denoted and distinguished from extensions, and
2. providing definitions for these attributes that cover many of the most common use cases for the say-as element.

2. Extension mechanism

In addition to the standardized interpret-as values defined in Section 3, vendors will likely wish to add their own. In discussing what changes might be necessary to SSML 1.0 to support this extensibility, the following criteria were established:

1. Backwards compatibility with VoiceXML built-in interpret-as values [VXML Appendix P] was essential
2. The group preferred that all say-as capability be accessible via the say-as element so that processors will at least recognize extensions to be say-as extensions.
3. A clear distinction between W3C-defined values and vendor-specific values would be made

To satisfy these criteria, the following further definition of the interpret-as attribute is provided:

The interpret-as attribute is a QName [SCHEMA2 §3.2.18]. A QName in the attribute's content is expanded into an expanded-name using the namespace declarations from the expression context. This is the same way expansion is done for element type names in start and end-tags except that the default namespace declared with xmlns is not used: if the QName does not have a prefix, then it is not considered to be in any namespace (this is the same way attribute names are expanded). It is an error [SSML §1.5] if the QName both does not have a prefix and is not explicitly defined in this document as a legal value. It is an error if the QName has a prefix for which there is no namespace declaration in the expression context.

<?xml version="1.0"?>
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
                   http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
         xmlns:example="http://www.example.com/say-as"
         xmlns:vxml="http://www.w3.org/2001/vxml"
         xml:lang="en-US">
  <p>This is a W3C-defined date:
       <say-as interpret-as="date" format="dm">4/6</say-as>.
     This is a VoiceXML date:
       <say-as interpret-as="vxml:date">????0604</say-as>.
     This is an example dot com date:
       <say-as interpret-as="example:date" format="weekandday">23/5</say-as>.
  </p>
</speak>

3. Defined interpret-as values

The following interpret-as values are defined to be legal values. These values must not be prefixed.

Implementation remarks

SSML [SSML] describes how illegal and/or malformed input, the presence or absence of the format attribute, and the presence or absence of the detail attribute are to be treated by the synthesis processor. The descriptions there apply to all of the interpret-as values in this section. It is especially worth noting that a synthesis processor should pronounce the contained text in a manner in which such content is normally produced for the language. Although the exact way content is read cannot be controlled by the say-as element, the processor should read it in a way that is applicable for the active locale or language.

Additionally, if the interpret-as and format attributes do not specify additional or different information than what the processor would have inferred automatically, then there should be no change in the pronounciation.

Note that some of the interpret-as value definitions include lexical token definitions to assist in explaining values of the format and detail attributes. There is no requirement that content adhere to these lexical representations. However, a processor that supports a particular interpret-as value should properly interpret content matching the lexical patterns given.

Finally, note that the additional information the say-as element provides to the synthesis processor may be useful in interpreting text outside the content of the element. In this example,

... occurred on <say-as interpret-as="date" format="mdy">12/26/04</say-as> at <say-as interpret-as="time" format="hms24">01:59:59</say-as> PST ...

the knowledge of the date and time data may assist the processor in determining that "PST" is to be interpreted as a time zone indicator.

3.1 Date

Specifying "date" as the interpret-as value indicates that the contained text is a Gregorian calendar date. Note that the say-as element then only gives a hint that the content is a Gregorian calendar date.

The format attribute

The optional format attribute can be used to indicate the format of a "date" string. In general, the format is a sequence of one or more digit groups, called fields, that are separated by a separator character. The same character must be used to delimit all fields in a date string. At least three separator characters must be supported: hyphen (-), forward slash (/), and dot (.). More details are specified under the section "Basic tokens of a date string".

The format attribute only indicates which fields are present and how they are ordered. Without an indication of the order the processor would sometimes not be able to unambiguously determine the underlying calendar date, e.g. "1/2/2004" could correspond with "February 1, 2004" or "January 2, 2004".

Note on XML Schema date types

Note that the "date" formats specified here do not correspond with XML Schema [SCHEMA2] or ISO 8601 [ISO 8601:2000] dates types. This is because the purpose of the say-as date type is different: it is to be able to correctly interpret date strings that are written in formats that are commonly used in human readable documents. The format attribute is typically used to help the processor to disambiguate between possible interpretations (e.g. day-month versus month-day).

The XML Schema and ISO 8601 date types are not sufficient because the SSML date strings are not necessarily in a canonical format (support for extra separator characters besides dashes and multiple field orderings). Moreover, synthesis processors [SSML §1.5] need to be able to process semantically invalid dates (like February 31) which XML Schema does not support.

Implementation remarks

Since "date" contents are pronounced in a manner appropriate for the language, it is possible for the synthesis processor to reorder the fields of a date if this results in a commonly used pronounciation. For example, the date 01/02/02 tagged as having the "dmy" (day-month-year) format in en-US context could be pronounced as "February, the first, zero two".
However, for "date" strings that a processor would correctly interpret without a say-as hint, the addition of the appropriate say-as information should not alter the way in which the date is pronounced.

The possible formats

Basic tokens of a date string

The following basic lexical tokens are used for dates:

[Day]: (0?[1...9]) | [10...31]

(one or two digits, optional leading zeros)

[Month]: (0?[1...9]) | [10...12]

(one or two digits, optional leading zero)

[Year]: (0?0?0?[0...9]) | (0?0?[10...99]) | (0?[100..999]) | ([1000..9999])

(one to four digits, optional century and optional leading zeros)

[Date Field Separator]: - | / | .

(hyphen, forward slash, or dot character)

Note that no white space is allowed inside a date string. Other single character separators may be supported at the synthesis processor's discretion.

Format: mdy

Lexical representation:

Examples:

<say-as interpret-as="date" format="mdy">3/6/02</say-as>
should be interpreted as the 6th of March, 02.

<say-as interpret-as="date format="mdy">09/21/2001</say-as>
should be interpreted as the 21st of September, 2001.

Format: dmy

Lexical representation:

Example:

<say-as interpret-as="date" format="dmy">01/02/1960</say-as>
should be interpreted as February first, 1960.

Format: ymd

Lexical representation:

Example:

<say-as interpret-as="date" format="ymd">1960-02-01</say-as>
should be interpreted as February first, 1960.

Format: md

Lexical representation:

Example:

<say-as interpret-as="date" format="md">11/12</say-as>
should be interpreted as November twelfth.

Format: dm

Lexical representation:

Format: ym

Lexical representation:

Format: my

Lexical representation:

Format: d

Lexical representation:

Format: m

Lexical representation:

Format: y

Lexical representation:

3.2 Time

Specifying "time" as the interpret-as value indicates that the contained text is a time. The intention is to cover most formats for time that might occur in a written document. Note that this format covers wall clock time only, not durations or time ranges.

The format attribute

The optional format attribute can be used to indicate the format of a "time" string. In general, the format is a sequence of one or more digit groups, called fields, that are separated by a separator character. The same character must be used to delimit all fields in a time string. At least one separator character must be supported: the colon (:). Synthesis processors may optionally support other separators (such as an "h" to separate the hour from the minute in French).

Note that the "time" formats specified here do not correspond to ISO 8601 [ISO 8601:2000] time types. This is because the purpose of the say-as time type is different; it is to allow a synthesis processor to be able to correctly interpret as times strings commonly written in human-readable documents.

Implementation remarks

Note that 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, as in the example below:

The synthesis processor may then, knowing that the content was a time, use that knowledge in interpreting the following "PST", for example as a time zone designation.

The possible formats

Basic tokens of a time string

The following basic lexical tokens are used in the format definitions that follow:

[hour]

an integer in the range [0-23]. Optional leading zero for hours less than 10.

[minute]

a two digit integer in the range [00-59].

[second]

a number in the range [0-60]. Leading zeros for seconds less than 10 are required. The number may be real-valued with arbitrary precision.
e.g. 13:00:15.752 and 13:00:15,752 mean "15.752 seconds after 1 o'clock in the afternoon."
The value 60 is used only to specify a "leap second" which occurs every few years. See [SCHEMA2 Appendix D.1] for details on the value 60.

[qualifier]

one of the following strings: "AM", "A.M.", "am", "a.m.", "A", "a", "PM", "P.M.", "pm", "p.m.", "P", "p"

[Time Field Separator]

colon (':') , dot ('.'), or empty string ("")
Other single character separators may be supported at the synthesis processor's discretion but must be documented.

[Qualifier Separator]

either white space or an empty string

Format: hms24

This is 24-hour (military) time format where the hour 00 corresponds to midnight and 23 corresponds to 11 o'clock in the evening.

The [minute] field and its preceding [Time Field Separator] are jointly optional.

The [second] field and its preceding [Time Field Separator] are jointly optional if the [minute] field is specified. The [second] field is not allowed if the [minute] field is not specified.

Lexical representation

Examples

<say-as interpret-as="time" format="hms24">00:00:00</say-as>
should be interpreted as midnight

<say-as interpret-as="time" format="hms24">000000</say-as>
should be interpreted as midnight

<say-as interpret-as="time" format="hms24">12:00:00</say-as>
should be interpreted as noon

<say-as interpret-as="time" format="hms24">9:21:30</say-as>
should be interpreted as 21 minutes and 30 seconds past the hour of 9 in the morning

<say-as interpret-as="time" format="hms24">01:59:59</say-as>
should be interpreted as 1 second before 2 o'clock in the morning

<say-as interpret-as="time" format="hms24">19:21:30.1</say-as>
should be interpreted as 21 minutes and 30.1 seconds past the hour of 7 in the evening

<say-as interpret-as="time" format="hms24">12.00</say-as>
should be interepreted as noon

<say-as interpret-as="time" format="hms24">00:01</say-as>
should be interpreted as one minute past midnight

<say-as interpret-as="time" format="hms24">1</say-as>
should be interpreted as one o'clock in the morning

<say-as interpret-as="time" format="hms24">115</say-as>
should be interpreted as 15 minutes past one in the morning

<say-as interpret-as="time" format="hms24">07.00</say-as>
should be interpreted as 7 o'clock in the morning

Format: hms12

This is 12-hour time format where the hours are restricted to the range 01 through 12.

The [minute] field and its preceding [Time Field Separator] are jointly optional.

The [second] field and its preceding [Time Field Separator] are jointly optional if the [minute] field is specified. The [second] field is not allowed if the [minute] field is not specified.

Specifying whether the time is before or after noon by using a [qualifier] is optional.

Lexical representation

Examples

<say-as interpret-as="time" format="hms12">09:21:15</say-as>
should be interpreted as 21 minutes and 15 seconds past the hour of 9, but whether this is morning or evening is left to the interpretation of the user

<say-as interpret-as="time" format="hms12">1200</say-as>
should be interpreted as either midnight or noon by the user

<say-as interpret-as="time" format="hms12">2</say-as>
should be interpreted as 2 o'clock (morning or afternoon to be interpreted by the user)

<say-as interpret-as="time" format="hms12">3.00</say-as>
should be interpreted as 3 o'clock (morning or afternoon to be interpreted by the user)

<say-as interpret-as="time" format="hms12">09:21:00PM</say-as>
should be interpreted as 21 minutes past the hour of 9 in the evening

<say-as interpret-as="time" format="hms12">07:21:00 a.m.</say-as>
should be interpreted as 21 minutes past the hour of 7 in the morning

<say-as interpret-as="time" format="hms12">12:00 am</say-as>
should be interpreted as midnight

<say-as interpret-as="time" format="hms12">12.00pm</say-as>
should be interpreted as noon

<say-as interpret-as="time" format="hms12">243P</say-as>
should be interpreted as 43 minutes after 2 in the afternoon

<say-as interpret-as="time" format="hms12">2p.m.</say-as>
should be interpreted as ten minutes past 2 o'clock in the afternoon

3.3 Telephone number

Specifying "telephone" as the interpret-as value indicates that the contained text is a telephone number. The intention is to give a hint to the synthesis processor how to interpret the contained text in order to speak it properly.

The format attribute

The optional format attribute can be used to indicate a country code. Values are strings of digits; see [ITU-CC] for a normative list of country codes defined by ITU-T.
This attribute will give a hint to the synthesis processor of the country code of the telephone number to be spoken. The synthesis processor may use this information to interpret the telephone number in the content. Note that the presence of the format attribute does not preclude the content from containing a country code, and that the country code in the content may differ from the value of the format attribute. In the latter case the content has priority over the attribute value.

Example uses of the format attribute:

<say-as interpret-as="telephone" format="1">(781) 771-7777</say-as>
this is a telephone number which is in use in North America.

<say-as interpret-as="telephone" format="1">1-866-TELLME-1</say-as>
this is a another telephone number which is in use in North America.

<say-as interpret-as="telephone" format="1">+39.800.123456</say-as>
this telephone number is in the country code "39" (that is Italy), even if the country code present in the format attribute does not match it.

The detail attribute

This attribute is not used for telephone content. Because no standard values of this attribute are defined, the synthesis processor is expected to ignore any values in this attribute that it does not support. See the say-as definition [SSML §3.1.8] for details.

Implementation remarks

Commonly the string of digits is spoken in a chunked way to highlight the structure of the number itself. However, the chunking algorithm itself is processor specific.

The possible formats

The content of a say-as with interpret-as="telephone" should contain a telephone number as it is commonly written by a user. The only limit to the range of characters that can occur within the content and be appropriately interpreted is that imposed by the synthesis processor itself. Some characters that might commonly occur, in addition to the digits 0-9, are separator characters to give a structure to the number itself, a prefix '+', letters that stand for numbers ("1-800-EXAMPLE"), and the characters '*' and '#'; of course, these characters are by no means the complete set of characters that may occur.

Examples:

Telephone numbers as digits

<say-as interpret-as="telephone" format="39">0117577577</say-as>
this is a telephone number which is in use in Italy (country code is "39"), for a local number.

<say-as interpret-as="telephone" format="81">0532441234</say-as>
this is a telephone number which is in use in Japan (country code is "81"), for a local number.

<say-as interpret-as="telephone" format="39">3477577577</say-as>
this is a telephone number which is in use in Italy (country code is "39"), for a mobile number.

<say-as interpret-as="telephone" format="81">09012345678</say-as>
<say-as interpret-as="telephone" format="81">08012345678</say-as>
these two are telephone numbers which are in use in Japan (country code is "81"), for a mobile number.

<say-as interpret-as="telephone" format="1">2123981900 </say-as>
this is a telephone number which is in use in NY area (country code is "1"), for a local number.

<say-as interpret-as="telephone">3981900 </say-as>
this is a telephone number, but it is not clear to which country it belongs.

<say-as interpret-as="telephone" format="39">800033033</say-as>
this is a telephone number which is in use in Italy (country code is "39"), for an 800 number.

<say-as interpret-as="telephone" format="81">0120123456</say-as>
<say-as interpret-as="telephone" format="81">0800123456</say-as>
these two are telephone numbers which are in use in Japan (country code is "81"), for toll-free domestic dialing.

<say-as interpret-as="telephone" format="81">800033033</say-as>
this is a telephone number which is in use in Japan (country code is "81"), for toll-free international dialing.

<say-as interpret-as="telephone">800255244</say-as>
this is an 800 telephone number, but it is not clear to which country it belongs.

Telephone numbers with separators

Examples from the previous section, but with some commonly used separators:

<say-as interpret-as="telephone" format="39">011.7577577</say-as>
this is a telephone number with common separators which is in use in Italy (country code is "39"), for a local number.

<say-as interpret-as="telephone" format="81">0532-44-1234</say-as>
<say-as interpret-as="telephone" format="81">(0532)44-1234</say-as>
these two are telephone numbers with common separators which are in use in Japan (country code is "81"), for local number .

<say-as interpret-as="telephone" format="39">347/7577577</say-as>
this is a telephone number with common separators which is in use in Italy (country code is "39"), for a mobile number.

<say-as interpret-as="telephone" format="81">090-1234-5678</say-as>
this is a telephone number with common separators which is in use in Japan (country code is "81"), for a mobile number.

<say-as interpret-as="telephone">090-1234-5678</say-as>
this is a telephone number with common separators, but it is not clear to which country it belongs.

<say-as interpret-as="telephone" format="39">800 0330334</say-as>
this is a telephone number with common separators which is in use in Italy (country code is "39"), for an 800 number.

<say-as interpret-as="telephone" format="81">0120-123456</say-as>
<say-as interpret-as="telephone" format="81">0120-12-3456</say-as>
<say-as interpret-as="telephone" format="81">0120-1234-56</say-as>
these examples are possible telephone numbers with common separators which are in use in Japan (country code is "81"), for toll-free domestic dialing.

<say-as interpret-as="telephone" format="1">212-398-1900</say-as>
this is a telephone number with common separators which is in use in NY area (country code is "1"), for a local number.

<say-as interpret-as="telephone">800.255.244</say-as>
this is an 800 telephone number with common separators, but it is not clear to which country it belongs.

Global telephone numbers

Some more examples which include the prefix "+" and the country code in the telephone number:

<say-as interpret-as="telephone" format="39">+39(011)777-7777</say-as>
<say-as interpret-as="telephone">+39(02)766-7676</say-as>
this is a telephone number which is in use in Italy (country code is "39"), for a local number.

<say-as interpret-as="telephone" format="81">+81(532)-44-1234</say-as>
<say-as interpret-as="telephone">+81 532 44 1234</say-as>
these two are telephone numbers which are in use in Japan for the local number.

<say-as interpret-as="telephone" format="39">+39.347.7577577</say-as>
this is a telephone number which is in use in Italy (country code is "39"), for a mobile number.

<say-as interpret-as="telephone" format="81">+81 90 7577 7577</say-as>
<say-as interpret-as="telephone">+81 90-7577-7577</say-as>
these two are telephone numbers which are in use in Japan for a mobile number.

<say-as interpret-as="telephone" format="39">+39-800-4141414</say-as>
this is a telephone number which is in use in Italy (country code is "39"), for an 800 number.

<say-as interpret-as="telephone">+1 212-398-1900 </say-as>
this is a telephone number which is in use in NY area (country code is "1"), for a local number.

Other telephone number examples

Some more examples of short numbers:

<say-as interpret-as="telephone" format="39">187</say-as>
this is a telephone number which is in use in Italy (country code is "39"), for TelecomItalia customer service.

<say-as interpret-as="telephone" format="39">4*</say-as>
these are two examples of the same telephone number which is in use in Italy (country code is "39"), for a short number to access many services offered by TelecomItalia.

<say-as interpret-as="telephone">6257</say-as>
this could be a telephone number local inside a company.

3.4 Character string

Specifying "characters" as the interpret-as value indicates that the enclosed text should be spoken as a series of alpha-numeric characters. (It is thus a generalization of the concept of digit string.) The text may include punctuation. The pronunciation of the individual characters is not indicated. For example, the digit '0' may be pronounced in English 'zero' or 'oh' or 'naught' at the discretion of the synthesis processor.

The format attribute

The format attribute can have one of the following two values:

• "glyphs"
• "characters"

If the format attribute is not specified, it defaults to "characters".

Format: glyphs

This indicates all characters should be read with glyph information, explicitly specifying uppercase/lowercase, accents, diacritics etc.

The purpose is to render the enclosed text in such a manner that it is unambiguously clear to the listener what the written text (glyphs) look like.

This is useful, for example, for arbitrary product numbers, passwords, given names, URLs, source code statements, formulas, and other similar character strings.

<say-as interpret-as="characters" format="glyphs">Jö_4 2</say-as>
capital J, o with umlaut, underscore, four, space, two

Format: characters

Reads all characters but doesn't provide distinction between different glyphs that could be used for the same character. For example, this format doesn't read uppercase/lowercase information.

The purpose is to render the enclosed text in such a manner that it is unambiguously clear which characters the text contains.

This is for example the case for spelling ordinary words or names if exact spelling (with accentuation) is not needed.

<say-as interpret-as="characters" format="characters">W3C</say-as>
double-you, three, c (and not capital double-you, three, capital C)

The detail attribute

The value of this attribute, if present, is a series of digits specifying how the characters are to be grouped. It is an error if the number of characters in the string does not match the total indicated in this parameter. The actual phonetic realization of the grouping is left up to the recognizer.

Examples

Consider the following code:

<say-as interpret-as="characters" format="characters" detail="3 1 2">1a3BZ7</say-as>

In this example, the synthesis processor begins with '1a3BZ7' as a string of characters, which the detail attribute instructs it to chunk into three groups, namely '1a3', 'B', and 'Z7'. One way the processor could realize this would be to pronounce the individual characters '1', 'a', and '3', followed by a pause, then the single character 'B', followed by another pause, then the characters 'Z' and '7'. However, the phonetic details of the realization are left up to the processor, including the intonational contour and the duration (and even the existence) of the pause.

3.5 Cardinal number

Specifying "cardinal" as the interpret-as value indicates that the enclosed text is an integral or decimal number and should be spoken as a cardinal number (as opposed to an ordinal number or digit string). An optional leading '-' or '+' is permitted to indicate negative (positive) numbers. Note that the exact rendering of the cardinal number is still determined by the synthesis processor.

The format attribute

This optional attribute indicates the character used to separate the integral and fractional parts of the number.

The detail attribute

This optional attribute indicates the character used to group the integral part of the number. In Western European languages this is normally the thousands separator, but other conventions may prevail for other languages.

If neither the format nor detail attribute is provided, the number will be parsed according to processor-specific defaults.

Examples

<say-as interpret-as="cardinal">1234567</say-as>
<say-as interpret-as="cardinal" detail=",">1,234,567</say-as>
These two examples, in North America, are likely to be spoken as "One million, two hundred thirty-four thousand, five hundred and sixty seven."

<say-as interpret-as="cardinal" format=".">123.456</say-as>
This example will likely be spoken as "One hundred twenty three point four five six."

<say-as interpret-as="cardinal" detail=".">123.456</say-as>
This example will likely be spoken as "One hundred twenty three thousand, four hundred and fifty six."

3.6 Ordinal number

Specifying "ordinal" as the interpret-as value indicates that the enclosed text is an integral number and should be spoken as an ordinal number (as opposed to a cardinal number or digit string). Note that numbers with separator characters such as 5,657 may be correctly interpreted by the synthesis processor at the processor's discretion.

As with all values of the interpret-as attribute, this one is a hint to the processor on how to interpret the contents. If the sentence containing the say-as element provides sufficient context for appropriate number and gender concordance, it is expected that the processor will produce the correct ordinal. If the context is not sufficient, the processor will produce the best representation of the ordinal that it can.

The format and detail attributes are not used for ordinal content. Because no standard values for these attributes are defined, the synthesis processor is expected to ignore any values in these attributes that it does not support. See the say-as definition [SSML §3.1.8] for details.

Examples

<say-as interpret-as="ordinal">123</say-as>
In English, this example will likely be spoken as "One hundred twenty third."

4. References

4.1 Normative References

[ITU-CC]

List of ITU-T Recommendation E.164 Assigned Country Codes. International Telecommunication Union, February 2004. This document is available at http://www.itu.int/itudoc/itu-t/ob-lists/icc/e164_763.html.

[SSML]

Speech Synthesis Markup Language (SSML) Version 1.0, D. Burnett, et al., Editors. World Wide Web Consortium, 7 September 2004. This version of the SSML Recommendation is http://www.w3.org/TR/2004/REC-speech-synthesis-20040907/. The latest version of SSML is available at http://www.w3.org/TR/speech-synthesis/.

[SCHEMA2]

XML Schema Part 2: Datatypes, P.V. Biron and A. Malhotra, Editors. World Wide Web Consortium, 2 May 2001. This version of the XML Schema Part 2 Recommendation is http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/. The latest version of XML Schema 2 is available at http://www.w3.org/TR/xmlschema-2/.

4.2 Informative References

[ISO 8601:2000]

Representation of dates and times. ISO (International Organization for Standardization), 8 June 2004. This document is available at http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=26780.

[VXML]

Voice Extensible Markup Language (VoiceXML) Version 2.0, S. McGlashan, et al., Editors. World Wide Web Consortium, 16 March 2004. This version of the VoiceXML 2.0 Recommendation is http://www.w3.org/TR/2004/REC-voicexml20-20040316/. The latest version of VoiceXML 2 is available at http://www.w3.org/TR/voicexml20/.

5. Acknowledgments

This document was written with the participation of the following participants in the W3C Voice Browser Working Group (listed in alphabetical order):

Dave Burke, VoxPilot
Ken Davies, HeyAnita
Max Froumentin, W3C
Jim Larson, Intel
Dave Raggett, W3C/Canon
Ellen Stuer, ScanSoft