Re: Offline webapps and speech UI

Agreed, browser settings are usually outside the scope of standards. If so
shouldn't we simply drop R.31 that allows users to select the recognizer,
especially if we agree about how important it is that a developer can select
it? I'm not averse to some general language specifying that 'the user agent
may under certain circumstances elect to ignore the developer requested
resource in favor of a local or alternate network resource, but generally
speaking developer requests should be honored', but specifically mentioning
browser controls seems like an implementation issue...

-Andy

> From: Satish Sampath <satish@google.com>
> Date: Wed, 3 Nov 2010 16:14:18 +0100
> To: Andy Mauro <Andy.Mauro@nuance.com>
> Cc: Bjorn Bringert <bringert@google.com>, <Olli@pettay.fi>,
> <public-xg-htmlspeech@w3.org>
> Subject: Re: Offline webapps and speech UI
> 
> Listing that would require defining what 'settings', 'modes' and
> 'specialized browsers' mean. Is there a precedent for this in any
> other standard or working draft? It also feels like it is quite early
> to get into such narrow specifics.
> 
> Cheers
> Satish
> 
> 
> 
> On Wed, Nov 3, 2010 at 4:09 PM, Andy Mauro <Andy.Mauro@nuance.com> wrote:
>> It'd be worth enumerating the 'settings, modes or specialized browsers' -
>> it's not obvious to me why any browser would want to ignore the developers
>> wishes to use a specialized resource excepting the offline scenario. Unless
>> we're very clear in specifying the expected default mode of operation and
>> the specific scenarios under which the defaults are not heeded there is room
>> for misuse, or more likely, misinterpretation which leads to developer AND
>> user pain because the quality and functionality of webapps cannot be
>> controlled.
>> 
>> -Andy
>> 
>> 
>>> From: Bjorn Bringert <bringert@google.com>
>>> Date: Wed, 3 Nov 2010 16:05:47 +0100
>>> To: Andy Mauro <Andy.Mauro@nuance.com>
>>> Cc: Satish Sampath <satish@google.com>, <Olli@pettay.fi>,
>>> <public-xg-htmlspeech@w3.org>
>>> Subject: Re: Offline webapps and speech UI
>>> 
>>> I think we agree that the intention is that typical browsers would by
>>> default follow the web app's requests. There may be settings, modes or
>>> specialized browsers that turn it off by default. As long as the
>>> browser lets the web app know, we won't be any worse off than if the
>>> browser had simply turned off or never implemented the speech input
>>> feature.
>>> 
>>> /Bjorn
>>> 
>>> On Wed, Nov 3, 2010 at 3:54 PM, Andy Mauro <Andy.Mauro@nuance.com> wrote:
>>>> It really boils down to what the default setting is ;) If it's to reject
>>>> developer requests for particular reco resources then we're likely not in
>>>> agreement since IMO this will cause apps to not work if a developer uses
>>>> recognizer specific functionality (which as much as I don't like this, is
>>>> the way it is today). If the default is to accept developer requests, and a
>>>> user has to manually modify the setting to use only local resources or an
>>>> alternate network resource, then I think all our goals are met (security,
>>>> privacy, app consistency)
>>>> 
>>>> -Andy
>>>> 
>>>>> From: Satish Sampath <satish@google.com>
>>>>> Date: Wed, 3 Nov 2010 15:49:51 +0100
>>>>> To: Andy Mauro <Andy.Mauro@nuance.com>
>>>>> Cc: Bjorn Bringert <bringert@google.com>, <Olli@pettay.fi>,
>>>>> <public-xg-htmlspeech@w3.org>
>>>>> Subject: Re: Offline webapps and speech UI
>>>>> 
>>>>>> I'm more concerned with the loophole that arises that seems to mean that
>>>>>> browsers can simply use their preferred recognizer all the time
>>>>>> irrespective
>>>>>> of developer choice.
>>>>> 
>>>>> I don't see that as a loophole, but akin to (2) in your list where the
>>>>> 'paranoid privacy setting' is 'downloading and using a browser which
>>>>> uses my preferred recognizer'.
>>>>> 
>>>>> - Satish
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Bjorn Bringert
>>> Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
>>> Palace Road, London, SW1W 9TQ
>>> Registered in England Number: 3977902
>> 
>> 
>>

Received on Wednesday, 3 November 2010 15:32:43 UTC