RE: Critical missing feature in SSML specification

maybe i'm missing something fundamental here, but i don't see how SSML
_can_support a <STOP> tag.

tags are part of a document. that document is submitted to a synthesiser.
the synthesiser processes the document and then looks for more input.

if a <STOP> tag is in the document, it is not much different from a </speak>
tag.

if a <STOP> tag is sent after the document, to request that the output be
aborted, that tag must be in a separate document which will not be processed
until after any previous documents.

what we're talking about here is a requirement for a "stop immediately"
command which is not part of any document but interrupts the processing of
the current document. there is no place for such a command in SSML as i
understand it: it belongs in a call control language, or an
application-specific API, or perhaps in a voiceweb metalanguage.

... or am i completely mistaken?

regards,
	alex.

> -----Original Message-----
> From:	Richard Schwerdtfeger [SMTP:schwer@us.ibm.com]
> Sent:	Wednesday, January 29, 2003 5:37 PM
> To:	www-voice@w3.org
> Cc:	w3c-wai-pf@w3.org
> Subject:	Critical missing feature in SSML specification
> Importance:	High
> 
> 
> 
> 
> 
> 
> In reviewing the SSML specification we (PF Group) overlooked an extremely
> critical missing feature in the last call draft.
> 
> It is absolutely essential that SSML support a <STOP> command.
> 
> Scenario:
> 
> Screen reader users will often hit the stop command to tell the speech
> synthesizer to stop speaking. Screen Readers would use the <MARK>
> annotation as a way to have the speech engine tell the screen reader when
> speech has been processed (marker processed). In the event that the user
> tells the screen reader to stop speaking the screen reader should be able
> to send a stop command to the speech engine which would utltimately flush
> the speech buffers. Markers not returned would help the screen reader know
> where the user left off in the user interface (maintain point of regard
> relative to what has been spoken).
> 
> I apologize for not submitting this in our last call review but this is a
> hard requirement. Otherwise, we SSML cannot support screen readers.
> 
> Rich
> 
> Rich Schwerdtfeger
> STSM, Software Group Accessibility Strategist
> Emerging Internet Technologies
> Chair, IBM Accessibility Architecture Review  Board
> schwer@us.ibm.com, Phone: 512-838-4593,T/L: 678-4593
> 
> "Two roads diverged in a wood, and I -
> I took the one less traveled by, and that has made all the difference.",
> Frost

Received on Wednesday, 29 January 2003 13:05:44 UTC