Copyright ©2005 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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.
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.
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
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:
To satisfy these criteria, the following further definition of the interpret-as attribute is provided:
Here is an example of how prefixes are expected to work: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>
The following interpret-as values are defined to be legal values. These values must not be prefixed.
interpret-as value | Defined in section |
date |
3.1 |
time |
3.2 |
telephone |
3.3 |
characters |
3.4 |
cardinal |
3.5 |
ordinal |
3.6 |
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.
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.
format
attributeThe 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 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.
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 following basic lexical tokens are used for dates:
[Day]: (0?[1...9]) | [10...31]
[Month]: (0?[1...9]) | [10...12]
[Year]: (0?0?0?[0...9]) | (0?0?[10...99]) | (0?[100..999]) |
([1000..9999])
[Date Field Separator]: - | / | .
Note that no white space is allowed inside a date string. Other single character separators may be supported at the synthesis processor's discretion.
mdy
[Month][Date Field Separator][Day][Date Field Separator][Year]
<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.
dmy
[Day][Date Field Separator][Month][Date Field Separator][Year]
<say-as interpret-as="date"
format="dmy">01/02/1960</say-as>
should be interpreted as February first, 1960.
ymd
[Year][Date Field Separator][Month][Date Field Separator][Day]
<say-as interpret-as="date"
format="ymd">1960-02-01</say-as>
should be interpreted as February first, 1960.
md
[Month][Date Field Separator][Day]
<say-as interpret-as="date"
format="md">11/12</say-as>
should be interpreted as November twelfth.
dm
[Day][Date Field Separator][Month]
ym
[Year][Date Field Separator][Month]
my
[Month][Date Field Separator][Year]
d
[Day]
m
[Month]
y
[Year]
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.
format
attributeThe 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.
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 time is <say-as interpret-as="time" format="hms12"> 10:00 AM
</say-as> PST.
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 following basic lexical tokens are used in the format definitions that follow:
[hour]
[minute]
[second]
[qualifier]
[Time Field Separator]
[Qualifier Separator]
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.
[hour]([Time Field Separator][minute]([Time Field
Separator][second])?)?
<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
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.
[hour]([Time Field Separator][minute]([Time Field
Separator][second])?)?([Qualifier Separator][qualifier])?
<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
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.
format
attributeThe 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.
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.
detail
attributeThis 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.
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 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.
<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.
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.
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.
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.
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.
format
attributeThe format
attribute can have one of the
following two values:
glyphs
"characters
"If the format
attribute is not specified, it
defaults to "characters
".
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.
Example:<say-as interpret-as="characters" format="glyphs">Jö_4
2</say-as>
capital J, o with umlaut, underscore, four, space, two
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.
Example:<say-as interpret-as="characters"
format="characters">W3C</say-as>
double-you, three, c (and not capital double-you, three, capital C)
detail
attributeThe 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.
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.
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.
format
attributeThis optional attribute indicates the character used to separate the integral and fractional parts of the number.
detail
attributeThis 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.
<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."
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.
<say-as interpret-as="ordinal">123</say-as>
In English, this example will likely be spoken as "One hundred twenty
third."
This document was written with the participation of the following participants in the W3C Voice Browser Working Group (listed in alphabetical order):