W3C home > Mailing lists > Public > www-style@w3.org > October 2011

Re: (SSML prosody@duration / voice-duration:<time>) Comments from PFWG on CSS3 Speech Module

From: Daniel Weck <daniel.weck@gmail.com>
Date: Tue, 18 Oct 2011 07:41:02 +0100
Cc: Janina Sajka <janina@rednote.net>, www-style list <www-style@w3.org>, Bert Bos <bert@w3.org>, List WAI Liaison <wai-liaison@w3.org>, List WAI PF <w3c-wai-pf@w3.org>, "paul.bagshaw@orange.com> <paul.bagshaw@orange.com" <paul.bagshaw@orange.com>
Message-Id: <C93DF850-DE25-46C7-BD11-F9C2A6E18965@gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>, Dan Burnett <dburnett@voxeo.com>, www-voice@w3.org
I would love to hear whether SSML's prosody@duration is a commonly-used feature. Perhaps we are unaware of an obvious use-case? Aslo, were there any major challenges with speech synthesizers when this feature was implemented in voice browsers?
Regards, Daniel

On 18 Oct 2011, at 01:16, fantasai wrote:

> On 10/15/2011 02:23 AM, Daniel Weck wrote:
>> On 15 Oct 2011, at 02:35, fantasai wrote:
>>> Hm, I'd say, if there isn't a use case, and it seems likely to have
>>> implementation and/or usability issues, and nobody has expressed a
>>> desire to have it, then it seems fair to drop it until someone
>>> requests it. We can copy the spec prose from the LC into a later
>>> spec if it turns out it's needed. What do you think?
>> (CC Voice-Browser group)
>> I assumed that the "at-risk" status was the most appropriate device to ensure that unwanted features do not end-up cluttering the final specification. The 'voice-duration' property has been in the CSS Speech drafts for a very long time [1], and it corresponds to a "non-disputed" feature in SSML. I wonder if removing it at this stage of the design process is judicious. Wouldn't running the course "as normal" be equally effective? (i.e. CR references implementations, or lack thereof)
> The at-risk status defers the decision of whether it stays in the standard
> to whether it will be implemented correctly or not. If we think a feature
> is not good to have, then we shouldn't include it even at-risk. Leaving
> it in the spec isn't entirely cost-free: it complicates the spec, and it
> encourages implementers to try implementing it. If we don't think it's useful,
> that's a waste of resources.
Received on Tuesday, 18 October 2011 06:42:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:06 UTC