Subject: RE: [Speechsc] General SpeechSC draft feedback

From: "Daniel Burnett" <[email-masked]>
Date: Thu, 6 May 2004 13:25:59 -0700

I should point out that we have had virtually 100% Scansoft participation and support for the features in the specification.  They have been worked out as compromises that permit the best of what vendors have to offer within a standard framework.  Not all features are needed by all vendors, but every feature was accepted in the document by all who have been participating.  We have all accepted features that only others needed, as is occasionally appropriate in any compromise-driven body such as a standards organization.
 
In my mind the key question is, "Is there a new problem that didn't exist in January when these extensions first appeared in the document?"  If the answer is no, then why don't we just finish up (since we're almost done) so adoption of the specification can begin?
 
-- dan
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Eberman, Brian
Sent: Thursday, May 06, 2004 11:40 AM
To: [email-masked]'
Cc: Reifenrath, Klaus
Subject: [Speechsc] General SpeechSC draft feedback

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

---

From: Jeff Kusnitz <[email-masked]>
Date: Thu, 6 May 2004 14:53:13 -0700

Example 1 at the bottom of page 65 has a small typo in it - the closing 
quotation mark is missing for the grammar URI (the same quotation mark is 
missing from the results in the example on page 71)

But that's not why I'm posting :-)  When a recognizer matches a grammar, 
it needs to process the semantic interpretation tags that are encoded in 
the grammar and return an NLSML document to the client.  What happens if 
the SI is somehow malformed such that a recognition engine can not process 
it after recognition has completed?  There doesn't seem to be an 
applicable return code - the recognition has completed successfully.

It seems another cause-code/name is in order?  And would the server return 
the incomplete NLSML results:

      S->C:MRCP/2.0 486 RECOGNITION-COMPLETE 543260 COMPLETE 
           Channel-Identifier: 32AECB23433801@speechrecog 
           Completion-Cause: 043 bad-semantic-tag
           Content-Type: applicationt/x-nlsml 
           Content-Length: 276 
 
           <?xml version="1.0"?> 
           <result x-model="http://IdentityModel" 
             xmlns:xf="http://www.w3.org/2000/xforms" 
             grammar="session:[email-masked]"> 
                <interpretation> 
                     <input>  may I speak to Andre Roy </input> 
                </interpretation> 
           </result>

Thanks,
Jeff 

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc