Subject: [Speechsc] General SpeechSC draft feedback

From: "Eberman, Brian" <[email-masked]>
Date: Thu, 6 May 2004 14:39:53 -0400

I'm concerned about the SpeechSC specification along a complexity axis and
portability axis.  This is going to make the standard unnecessarily brittle
and will slow adoption of what ScanSoft feels is a critical specification. 
 
In designing the originally specification we focused on some critical tests:
 
1) Platform not application portability --  is this piece of the
specification required for platform communication portability or is it
required for the application portability and is it attempting to standardize
the application dev model. If its for the platform and is something the
platform must know then it needs to be in the standard, otherwise its an
extension point.   The ASR section is getting very complex and difficult to
understand and there are sections in there that I'm not convinced are
required for anything except application portability. 
 
For example the timers for hot-word are not required in some of the hot-word
implementations we do and why does the platform needs these variables.
 
2) Minimal messages --- we worked to make sure that the communication and
messages were minimal. If a task could be accomplished within the standard
even if the mechanism was not completely clear then it was sufficient, no
syntactic sugar should be in the spec.
 
For example now there is an entire section on voice enrollment. However the
current v 1 specification is quite sufficient for voice enrollment.
ScanSoft's solution can do voice enrollment already with the current
specification. So why are we adding a significant amount of overhead to the
specification to standardize a mechanism that isn't required.  If extensions
to return results are required to provide a more general mechanism then we
are in favor of that.
 
Second if something could be done with the current messages then it
shouldn't be replicated by other means. For example now there is a parameter
for the Recognize command that controls if it dequeues other recognizes that
may have already been sent. A STOP already has this functionality.
 
3) Simplicity of the device -- we assumed that the device could perform
actions very quickly and that it was as near stateless as possible. We
wanted to make sure that if it failed a new device could come in and take
over with minimal disruption to the service.  Both the verification and
voice enrollment specifications currently violate this approach.
 
4) Separation of services -  Some significant progress has been made in this
area and it needs to continue. This is the key problem of how you build a
VXML device that doesn't have to see the audio.  We are preparing a
discussion on coordination of RTP playback that will be needed in the TTS
section to help drive this.
 
-Brian Eberman