- From: Young, Milan <Milan.Young@nuance.com>
- Date: Tue, 7 Dec 2010 14:40:09 -0800
- 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>
- Message-ID: <1AA381D92997964F898DF2A3AA4FF9AD09981B20@SUN-EXCH01.nuance.com>
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 agreement": * 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, payload? 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. Thanks ________________________________ 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; public-xg-htmlspeech@w3.org 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 communication. 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. http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_request 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. -- Cheers Satish
Received on Tuesday, 7 December 2010 22:40:47 UTC