W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2003

RE: [SSML Last Call] "say-as" element creates under-modeled marku p

From: Daniel Burnett <burnett@nuance.com>
Date: Fri, 8 Aug 2003 17:02:39 -0700
Message-ID: <ED834EE1FDD6C3468AB0F5569206E6E91AF300@MPB1EXCH02.nuance.com>
To: <Alex.Monaghan@Aculab.com>
Cc: <www-voice@w3.org>

Dear Alex,

Thank you for your further comments on the most recent specification draft.

We have Accepted this request (with changes).
Here's our response:

>>> As stated in the second paragraph of 2.1.4, the Working Group
>>> expects to produce a separate document that will define values
>>> for the interpret-as, format, and detail attributes. There is
>>> significant interest within the WG in defining these values,
>>> but not at the expense of delaying the publication of SSML 1.0.
>>> For that reason, this definition work is slated to begin when
>>> the SSML 1.0 specification reaches the Candidate Recommendation stage.

If you believe we have not adequately addressed your request,
please let us know as soon as possible.  If we do not hear
from you within 14 days, we will take this as tacit acceptance.

Again, thank you for your input.

-- Dan Burnett
Synthesis Team Leader, VBWG

-----Original Message-----
From: Alex.Monaghan@Aculab.com [mailto:Alex.Monaghan@Aculab.com]
Sent: Friday, January 24, 2003 2:13 AM
To: www-voice@w3.org
Subject: RE: [SSML Last Call] "say-as" element creates under-modeled
marku p



colleagues,
there has obviously been a deliberate decision to remove the finite set of
defined attibutes from the "say-as" specification, and replace them with an
infnite set of unspecified attributes. it would be interesting to know why
this decision was taken: was it to increase the ease of conformance, or to
increase flexibility, or because the finite set was getting too big to
handle?

in any case, al gilman's points seem valid. particularly, there are some
obvious and easily-understood types which should be specifiable using the
"say-as" tag (e.g. number, acronym, spell-out) where all systems should use
the same attribute names. of course there are other (sub)types which are not
relevant to all languages or domains: morphological case on ordinal numbers
in Finnish, or pronunciation of chemical formulae, for instance.

by all means allow the inclusion of additional (sub)types of "say-as", but
please bring back the requirement for standard treatment of basic types, and
please ensure that additional types are properly specified.

thanks,
	alex.

> -----Original Message-----
> From:	Al Gilman [SMTP:asgilman@iamdigex.net]
> Sent:	Friday, January 24, 2003 3:20 AM
> To:	www-voice@w3.org
> Subject:	[SSML Last Call] "say-as" element creates under-modeled
> markup
> 
> 
> 
> <note>
> 
> Sorry this is late.
> 
> In view of the timing, this comment has not been discussed in the PF
> group.
> It is, however, based on a clash between the design of the "say-as"
> construct and the goals set out in the current draft of the XML
> Accessibility Guidelines (XAG), which has been discussed there quite a
> bit.
> 
> References:
> 
> "say-as" element
> http://www.w3.org/TR/speech-synthesis/#S2.1.4
> 
> XAG Checkpoint 2, (have a model) and 4 (export the model):
> http://www.w3.org/TR/xag#g2_0
> http://www.w3.org/TR/xag#g4_0
> 
> </note>
> 
> The say-as element has attributes names "interpret-as" and "format."
> However, the format specification neither defines these in such as way
> as to create an interoperable information capture, nor does it require
> the user of these attributes to do so in user-provided declarations.
> 
> The examples given of ordinal numbers and telephone numbers, on the other
> hand, are clear examples of information elements with well-posed value
> domains and application semantics.  This categorical information would be
> valuable in a variety of adaptation to meet the needs of people with
> disabilities, such as re-representing the information in modes other than
> speech.
> 
> A XAG-compliant dialect would ensure that all interpret-as and format
> values assigned to speak-able strings were machinably connected with
> machine-comprehensible expressions of the proper characteristics
> where machine-comprehensible expression of such characteristics was
> readily achievable.
> 
> In fact, in the use cases suggested in the examples, the 'format'
> attribute
> is used for indicating the semantic variety involved, while the
> "interpret-as" attribute is used for the more presentation-level encoding
> of
> these information items in overloads of the integers.
> 
> This element in violation of XAG Checkpoint 4.9, "Do not assume that
> element
> or attribute names provide any information about element semantics."  It
> is
> ironically so, in that the name at least for the 'format' attribute is the
> opposite of its suggested usage.
> 
> There is no semantics actually defined for these attributes, except for
> possible heuristic values which are clearly only understood within the
> working group, as they in some cases are the reverse of common usage.
> These
> two attributes are semantically as specific as the html:any.class
> attribute,
> but named in a way as to appear more specific although they are not.  The
> language would be better off to stick with .class as in HTML if there in
> no
> semantic backup for the values applied under these names, but the format
> should set up mechanisms for backups as to the sense of the values of
> marks
> which guide the same rendering decisions as here, and not leave these as
> bare user-defined strings.
> 
> This syntax, or the HTML-like .class attribute syntax, could perhaps be
> characterized in metadata and brought up to a level of definition meeting
> XAG Guideline 4.
> 
> On the other hand, the information to be conveyed by markup with this
> element could be spelled out in the metadata section.
> 
> In future production use the information that "say-as" is designed to
> denote
> should mostly be handled by lexicon references, but the lexicon standard
> is
> not there yet.  But a dc.relation.conformsTo link to a type declaration in
> the XSD type system would be a feasible form of inline lexicon support for
> the kinds of characteristics that seem to be targeted here.
> 
> Please consider ways that we can get the value domain and appropriate
> application information that goes with these information elements better
> exposed for processing in adaptive applications.
> 
> There is information that this element is trying to capture that is very
> important in speech rendering of texts.  It is just not modeled well in
> this
> language feature.  The markup should focus on the content species.  An
> ordinal number, for example, is a well known conceptual species; there are
> multiple definitions in standards that one could refer to, to convey its
> nature.  This will give the speech generation module what it needs by way
> of
> decision basis in order to inflect the voicing appropriately.  An
> un-defined
> user-inserted string doesn't establish a basis for interoperation with
> respect
> to the applicable semantics.  This has been clear from the history of
> 'rel'
> and 'rev' on html:link and similar attributes elsewhere.
> 
> Al
Received on Friday, 8 August 2003 20:11:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:48:58 GMT