W3C home > Mailing lists > Public > public-xg-htmlspeech@w3.org > December 2010

RE: UA <=> SS Protocol

From: Young, Milan <Milan.Young@nuance.com>
Date: Tue, 7 Dec 2010 14:40:09 -0800
Message-ID: <1AA381D92997964F898DF2A3AA4FF9AD09981B20@SUN-EXCH01.nuance.com>
To: "Satish Sampath" <satish@google.com>, "Bjorn Bringert" <bringert@google.com>
Cc: "Marc Schroeder" <marc.schroeder@dfki.de>, "Robert Brown" <Robert.Brown@microsoft.com>, "Dave Burke" <daveburke@google.com>, <public-xg-htmlspeech@w3.org>
Other than Google, I'm not aware of any vendors that support HTTP as an
open protocol of communication with recognition/synthesis resources.
I'm not objecting to such a requirement, but we need to identify all
such assumptions in our recommendation.


I'm also becoming increasingly leery of the hand waving within the
Device API theme.  Just because we may have identified an alternative to
bogging ourselves down with low-level protocol definition doesn't free
us from the need to define the higher one.


A few details which I believe should not fall under "bilateral

*         Standard mechanism for passing parameters.  Do we use
setRequestHeader() or send this in the payload?

*         Standard definition on how events are passed from server to
client.  Are these sent within the HTTP protocol (eg Continue), as
headers, or perhaps as payload data in a chunked response?

*         Standard means for encoding grammars and synthesis requests.
I believe MRCP provides a good model for this already.

*         Standard format for default result types.  Plain text, JSON,
or XML?

*         Standard means for preserving session.  Cookies, HTTP headers,


The above isn't an exhaustive list, and perhaps some of the questions
have obvious solutions.  But I don't see how we can achieve our
interoperability charter without going in this direction.







From: Satish Sampath [mailto:satish@google.com] 
Sent: Tuesday, December 07, 2010 12:27 PM
To: Bjorn Bringert
Cc: Young, Milan; Marc Schroeder; Robert Brown; Dave Burke;
Subject: Re: UA <=> SS Protocol


	> Our recommendation would still need to state that all Speech
Services and UAs must support XmlHttpRequest as a means of


Top browsers/UAs already support it and the ones who haven't done yet
will most likely have it by the time our XG produces the deliverables
late next year.



Regarding speech services supporting it - XMLHttpRequest is a client
side technology implemented in UAs and what servers receive will be
standard http requests. They don't have to do anything special if they
already provide a http API.




Received on Tuesday, 7 December 2010 22:40:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:16:48 UTC